Fluid production network leak detection system

ABSTRACT

A method can include receiving real time data where the real time data include at least pressure sensor data from multiple pressure sensors of a hydrocarbon fluid production network for multiple locations in the hydrocarbon fluid production network; generating an expected operational region in a multidimensional domain using at least a portion of the real time data; operating a leak detection system using the expected operational region; tracking at least a portion of the real time data in the multidimensional domain; and issuing a leak detection signal responsive to the tracking indicating an excursion from the expected operational region, where the leak detection signal indicates the presence of a leak in the hydrocarbon fluid production network.

RELATED APPLICATION

This application claims priority to and the benefit of a US Provisional application having Ser. No. 63/122,346, filed 7 Dec. 2020, which is incorporated by reference herein.

BACKGROUND

Production systems can provide for transportation of fluids from well locations to processing facilities, from processing facilities to well locations, etc. Such fluid may be single or multiphase and include one or more hydrocarbon fluids (e.g., oil, natural gas, etc.) and may include one or more other fluids (e.g., water, etc.). As an example, a system may include a substantial number of flowlines and pieces of production equipment, for example, interconnected at junctions to form a network, which may be referred to as a fluid production network.

SUMMARY

A method can include receiving real time data where the real time data include at least pressure sensor data from multiple pressure sensors of a hydrocarbon fluid production network for multiple locations in the hydrocarbon fluid production network; generating an expected operational region in a multidimensional domain using at least a portion of the real time data; operating a leak detection system using the expected operational region; tracking at least a portion of the real time data in the multidimensional domain; and issuing a leak detection signal responsive to the tracking indicating an excursion from the expected operational region, where the leak detection signal indicates the presence of a leak in the hydrocarbon fluid production network. A leak detection system can include a processor; memory accessible by the processor; and processor-executable instructions stored in the memory where the instructions include instructions to instruct the leak detection system to: receive real time data where the real time data include at least pressure sensor data from multiple pressure sensors of a hydrocarbon fluid production network for multiple locations in the hydrocarbon fluid production network; generate an expected operational region in a multidimensional domain using at least a portion of the real time data; operate a leak detection system using the expected operational region; track at least a portion of the real time data in the multidimensional domain; and issue a leak detection signal responsive to the tracking indicating an excursion from the expected operational region, where the leak detection signal indicates the presence of a leak in the hydrocarbon fluid production network. One or more computer-readable storage media can include computer-executable instructions executable by a computer, the instructions include instructions to: receive real time data where the real time data include at least pressure sensor data from multiple pressure sensors of a hydrocarbon fluid production network for multiple locations in the hydrocarbon fluid production network; generate an expected operational region in a multidimensional domain using at least a portion of the real time data; operate a leak detection system using the expected operational region; track at least a portion of the real time data in the multidimensional domain; and issue a leak detection signal responsive to the tracking indicating an excursion from the expected operational region, where the leak detection signal indicates the presence of a leak in the hydrocarbon fluid production network.

This summary is provided to introduce a selection of concepts that are further described below in the detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in limiting the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of the described implementations can be more readily understood by reference to the following description taken in conjunction with the accompanying drawings.

FIG. 1 illustrates an example field system that includes various components, an example of a method and an example of a device or system;

FIG. 2 illustrates an example of a system and an example of a ternary diagram with an example of an associated table of fluid properties;

FIG. 3 illustrates an example of a system;

FIG. 4 illustrates an example of a network, an example of a system and examples of instructions;

FIG. 5 illustrates an example of a system and an example of a geologic environment and equipment;

FIG. 6 illustrates an example of a method;

FIG. 7 illustrates an example of a portion of a fluid production network;

FIG. 8 illustrates an example of a system that can perform leak detection;

FIG. 9 illustrates an example of a system;

FIG. 10 illustrates an example of a system;

FIG. 11 illustrates an example of a system;

FIG. 12 illustrates an example of a system;

FIG. 13 illustrates an example of a system;

FIG. 14 illustrates an example of a system;

FIG. 15 illustrates an example of a graphical user interface;

FIG. 16 illustrates an example of a graphical user interface;

FIG. 17 illustrates an example of a graphical user interface;

FIG. 18 illustrates an example of a graphical user interface;

FIG. 19 illustrates an example of a graphical user interface;

FIG. 20 illustrates an example of a graphical user interface;

FIG. 21 illustrates an example of a graphical user interface;

FIG. 22 illustrates an example of a graphical user interface;

FIG. 23 illustrates an example of a graphical user interface;

FIG. 24 illustrates an example of a graphical user interface;

FIG. 25 illustrates an example of a graphical user interface;

FIG. 26 illustrates an example of a graphical user interface;

FIG. 27 illustrates an example of a graphical user interface;

FIG. 28 illustrates an example of a graphical user interface;

FIG. 29 illustrates an example of a graphical user interface;

FIG. 30 illustrates an example of a graphical user interface;

FIG. 31 illustrates an example of a graphical user interface;

FIG. 32 illustrates an example of a graphical user interface;

FIG. 33 illustrates an example of a graphical user interface;

FIG. 34 illustrates an example of a graphical user interface;

FIG. 35 illustrates an example of a computing system; and

FIG. 36 illustrates example components of a system and a networked system.

DETAILED DESCRIPTION

The following description includes the best mode presently contemplated for practicing the described implementations. This description is not to be taken in a limiting sense, but rather is made merely for the purpose of describing the general principles of the implementations. The scope of the described implementations should be ascertained with reference to the issued claims.

FIG. 1 shows an example of a geologic environment 110 that includes reservoirs 111-1 and 111-2, which may be faulted by faults 112-1 and 112-2, an example of a method 150 and an example of a device or system 170. FIG. 1 also shows some examples of offshore equipment 114 for oil and gas operations related to the reservoir 111-2 and onshore equipment 116 for oil and gas operations related to the reservoir 111-1.

As an example, a model may be made that models a geologic environment in combination with equipment, wells, etc. For example, a model may be a flow simulation model for use by a simulator to simulate flow in an oil, gas or oil and gas production system. Such a flow simulation model may include equations, for example, to model multiphase flow from a reservoir to a wellhead, from a wellhead to a reservoir, etc. A flow simulation model may also include equations that account for flowline and surface facility performance, for example, to perform a comprehensive production system analysis.

As an example, a flow simulation model may be a network model that includes various sub-networks specified using nodes, segments, branches, etc. As an example, a flow simulation model may be specified in a manner that provides for modeling of branched segments, multilateral segments, complex completions, intelligent downhole controls, etc. As an example, one or more portions of a production network (e.g., optionally sub-networks, etc.) or a group of signal components and/or controllers may be modeled as sub-models.

As an example, a system may provide for transportation of oil and gas fluids from well locations to processing facilities and may represent a substantial investment in infrastructure with both economic and environmental impact. Simulation of such a system, which may include hundreds or thousands of flow lines and production equipment interconnected at junctions to form a network, can involve multiphase flow science and, for example, use of engineering and mathematical techniques for large systems of equations.

As an example, a flow simulation model may include equations for performing nodal analysis, pressure-volume-temperature (PVT) analysis, gas lift analysis, erosion analysis, corrosion analysis, production analysis, injection analysis, etc. In such an example, one or more analyses may be based, in part, on a simulation of flow in a modeled network.

As to nodal analysis, it may provide for evaluation of well performance, for making decisions as to completions, etc. A nodal analysis may provide for an understanding of behavior of a system and optionally sensitivity of a system (e.g., production, injection, production and injection). For example, a system variable may be selected for investigation and a sensitivity analysis performed. Such an analysis may include plotting inflow and outflow of fluid at a nodal point or nodal points in the system, which may indicate where certain opportunities exist (e.g., for injection, for production, etc.).

A modeling framework may include instructions (e.g., processor-executable instructions) to facilitate generation of a flow simulation model. For example, instructions may provide for modeling completions for vertical wells, completions for horizontal wells, completions for fractured wells, etc. A modeling framework may include instructions for particular types of equations, for example, black-oil equations, equation-of-state (EOS) equations, etc. A modeling framework may include instructions for artificial lift, for example, to model fluid injection, fluid pumping, etc. As an example, consider a set of instructions (e.g., a component) that includes features for modeling one or more electric submersible pumps (ESPs) (e.g., based in part on pump performance curves, motors, cables, etc.).

As an example, an analysis using a flow simulation model may be a network analysis to: identify production bottlenecks and constraints; assess benefits of new wells, additional pipelines, compression systems, etc.; calculate deliverability from field gathering systems; predict pressure and temperature profiles through flow paths; or plan full-field development.

As an example, a flow simulation model may provide for analyses with respect to future times, for example, to allow for optimization of production equipment, injection equipment, etc. As an example, consider an optimal time-based and conditional-event logic representation for daily field development operations that can be used to evaluate drilling of new developmental wells, installing additional processing facilities over time, choke-adjusted wells to meet production and operating limits, shutting in of depleting wells as reservoir conditions decline, etc.

As to equations, sets of conservation equations for mass momentum and energy describing single, two or three phase flow (e.g., according to one or more of a LEDAFLOW™ (Kongsberg Oil & Gas Technologies AS, Sandvika, Norway), OLGA™ model (Schlumberger Ltd, Houston, Texas), TUFFP unified mechanistic models (Tulsa University Fluid Flow Projects, Tulsa, Oklahoma), etc.).

As to the method 150 of FIG. 1 , it can include a build block 152 for building a network model that represents a production system for fluid; an assignment block 154 for assigning equations to sub-networks in the network model (e.g., where at least one of the sub-networks is optionally assigned equations formulated for solving for pressure and momentum implicitly and simultaneously, conservation mass and energy/temperature in separate stages), a provision block 156 for providing data; a transfer block 158 for transferring the data to the network model; and a simulation block 160 for simulating physical phenomena associated with the production system using the network model to provide simulation results.

The method 150 is shown in FIG. 1 in association with various computer-readable media (CRM) blocks 153, 155, 157, 159 and 161. Such blocks generally include instructions suitable for execution by one or more processors (or processing cores) 172 to instruct the computing device or system 170 to perform one or more actions. While various blocks are shown, a single medium may be configured with instructions to allow for, at least in part, performance of various actions of the method 150. As an example, a computer-readable medium (CRM) may be a computer-readable storage medium that is not a carrier wave, for example, such as a memory device 174 of the computing device or system 170, where the memory device 174 includes memory.

A production system can include equipment, for example, where a piece of equipment of the production system may be represented in a sub-network of a network model (e.g., optionally as a sub-model or sub-models, etc.) and, for example, assigned equations formulated to represent the piece of equipment. As an example, a piece of equipment may include an electric motor operatively coupled to a mechanism to move fluid (e.g., a pump, compressor, etc.). As an example, a piece of equipment may include a heater coupled to a power source, a fuel source, etc. (e.g., consider a steam generator). As an example, a piece of equipment may include a conduit for delivery of fluid where the fluid may be for delivery of heat energy (e.g., consider a steam injector). As an example, a piece of equipment may include a conduit for delivery of a substance (e.g., a chemical, a proppant, etc.).

As an example, a sub-network may be assigned equations formulated to represent fluid at or near a critical point, to represent heavy oil, to represent steam, to represent water or one or more other fluids (e.g., optionally subject to certain physical phenomena such as pressure, temperature, etc.).

As an example, a system can include a processor; a memory device having memory accessible by the processor; and processor-executable instructions stored in the memory of the memory device, the instructions executable to instruct the system to: build a network model that represents a production system for fluid, assign equations to sub-networks in the network model, provide data, transfer the data to the network model, and simulate physical phenomena associated with the production system using the network model to provide simulation results.

As an example, a system can include a sub-network assigned equations formulated for steam associated with equipment for an enhanced oil recovery (EOR) process (e.g., steam-assisted gravity drainage (SAGD) and/or other FOR process).

As an example, a system can include a sub-network that represents a piece of equipment of a production system by assigning that sub-network equations formulated to represent the piece of equipment. In such an example, the piece of equipment may include an electric motor operatively coupled to a mechanism to move fluid (e.g., a compressor, a pump, etc.).

As an example, one or more computer-readable media can include computer-executable instructions executable by a computer to instruct the computer to: receive simulation results for physical phenomena associated with a production system modeled by a network model; and analyze the simulation results.

FIG. 2 shows an example of a schematic view of a portion of a geologic environment 201 that includes equipment and an example of a ternary diagram 250 with an example of a table 260 of associated fluid properties. As shown in FIG. 2 , the environment 201 includes a wellsite 202, a network 203 and various examples of surface process equipment such as, for example, a separator 244, a compressor 254 and a pump 256. The wellsite 202 includes a wellbore 206 extending into earth as completed and prepared for production of fluid from a reservoir 211.

In the example of FIG. 2 , wellbore production equipment 264 extends from a wellhead 266 of the wellsite 202 and to the reservoir 211 to draw fluid to the surface. As shown, the wellsite 202 is operatively connected to the network 203 via a transport line 261 (e.g., a pipeline). As indicated by various arrows, fluid can flow from the reservoir 211, through the wellbore 206 and onto the network 203 and to a portion thereof 244. Fluid can then flow from the portion of the network 244, for example, to one or more fluid processing facilities.

In the example of FIG. 2 , sensors (S) are located, for example, to monitor various parameters during operations. The sensors (S) may measure, for example, pressure, temperature, flowrate, composition, and other parameters of the reservoir, wellbore, gathering network, process facilities and/or other portions of an operation. As an example, the sensors (S) may be operatively connected to a surface unit 216 (e.g., to instruct the sensors to acquire data, to collect data from the sensors, etc.).

In the example of FIG. 2 , the surface unit 216 can include various components, such as, for example, a memory device 220, a controller 222, one or more processors 224, one or more interfaces 225 and display unit 226 (e.g., for managing data, visualizing results of an analysis, etc.). As an example, data may be collected in the memory device 220 and processed by at least one of the one or more processor(s) 224 (e.g., for analysis, etc.). As an example, data may be collected from the sensors (S) and/or by one or more other sources. For example, data may be supplemented by historical data collected from other operations, user inputs, etc. As an example, analyzed data may be used to in a decision-making process.

In the example of FIG. 2 , a transceiver may be provided to allow communications between the surface unit 216 (e.g., via one or more of the interfaces 225) and one or more pieces of equipment in the environment 201 (e.g., one or more equipment interfaces, which may be wired and/or wireless). For example, the controller 222 may be used to actuate mechanisms in the environment 201 via the transceiver, optionally based on one or more decisions of a decision-making process. In such a manner, equipment in the environment 201 may be selectively adjusted based at least in part on collected data. Such adjustments may be made, for example, automatically based on computer protocol, manually by an operator or both. As an example, one or more well plans may be adjusted (e.g., to select optimum operating conditions, to avoid problems, etc.). In the example of FIG. 2 , a network may be established that is a device network for purposes of transmission and receipt of information (e.g., via network interfaces).

To facilitate data analyses, one or more simulators may be implemented (e.g., optionally via the surface unit 216 or other unit, system, etc.). As an example, data fed into one or more simulators may be historical data, real time data or combinations thereof. As an example, simulation through one or more simulators may be repeated or adjusted based on the data received.

In the example of FIG. 2 , simulators can include a reservoir simulator 228, a wellbore simulator 230, and a surface network simulator 232, a process simulator 234 and an economics simulator 236. As an example, the reservoir simulator 228 may be configured to solve for hydrocarbon flow rate (e.g., and optionally one or more pressures) through a reservoir and into one or more wellbores. As an example, the wellbore simulator 230 and surface network simulator 232 may be configured to solve for hydrocarbon flow rate (e.g., and optionally one or more pressures) through a wellbore and a surface gathering network of pipelines. As to the process simulator 234, it may be configured to model a processing plant where fluid containing hydrocarbons is separated into its constituent components (e.g., methane, ethane, propane, etc.), for example, and prepared for further distribution (e.g., transport via road, rail, pipe, etc.) and optionally sale. As an example, the economics simulator 236 may be configured to model costs associated with at least part of an operation. For example, consider MERAK™ framework (Schlumberger Limited, Houston, Texas), which may provide for economic analyses.

In FIG. 2 , the ternary diagram 250 includes vertices that represent single-phase gas, oil and water, while the sides represent two phase mixtures (e.g., gas-oil, oil-water and gas-water) and points within the triangle represents a three-phase mixture. The transition region indicates where the liquid fraction changes from water in oil to oil in water and vice versa (e.g., consider emulsions).

The ternary diagram 250 of FIG. 2 also indicates some examples of ranges of multiphase flow regimes, which may be affected by one or more factors such as, for example, temperature, pressure, viscosity, density, flowline orientation, etc. The example flow regimes include annular mist, slug flow and bubble flow; noting that other types may occur (e.g., stratified, churn, disperse, etc.). Annular mist flow may be characterized by, for example, a layer of liquid on the wall of a pipe and droplets of liquid in a middle gas zone (e.g., mist). Slug flow may be characterized by, for example, a continuous liquid phase and a discontinuous liquid phase that is discontinuous due to separation by pockets of gas. Bubble flow may be characterized by, for example, two continuous liquid phases where at least one of the continuous liquid phases includes gas bubbles. The illustrative graphics of flow regimes in FIG. 2 correspond to flows in approximately horizontal conduits; noting that a conduit may be disposed at an angle other than horizontal and that various factors that can influence flow may depend on angle of a conduit. For example, the angle of a conduit with respect to gravity can have an influence on how fluid flows in the conduit.

The table 260 of FIG. 2 shows viscosity and density as fluid properties. As to one or more other properties, consider, for example, surface tension. As indicated, the table 260 can include information for points specified with respect to the ternary diagram 250. As an example, factors such as pressure, volume and temperature may be considered, for example, as to values of fluid properties, phases, flow regimes, etc.

As an example, information as to flow of fluid may be illustrated as a flow regime map that identifies flow patterns occurring in various parts of a parameter space defined by component flow rates. For example, consider flow rates such as volume fluxes, mass fluxes, momentum fluxes, or one or more other quantities. Boundaries between various flow patterns in a flow regime map may occur where a regime becomes unstable and where growth of such instability causes transition to another flow pattern. As in laminar-to-turbulent transition in single phase flow, multiphase transitions may be rather unpredictable as they may depend on otherwise minor features of the flow, such as the roughness of the walls or the entrainment and entrance conditions. Thus, as indicated in the ternary diagram 250, flow pattern boundaries may lack distinctiveness and exhibit transition zones.

As to properties, where fluid is single phase (e.g., water, oil, or gas), a single value of viscosity may suffice for given conditions. However, where fluid is multiphase, two or more concurrent phases may occupy a flow space within a conduit (e.g., a pipe). In such an example, a single value of viscosity (e.g., or density) may not properly characterize the fluid in that flow space. Accordingly, as an example, a value or values of mixture viscosities may be used, for example, where a mixture value is a function of phase fraction(s) for fluid in a multiphase flow space.

As to surface tension (e.g., a), it may be defined for gas and liquid, for example, where the liquid may be oil or water. Where two-phase liquid-liquid flow exists (e.g., water and oil), then a may reflect the interfacial tension between oil and water (see, e.g., the slug flow regime and the bubble flow regime).

FIG. 3 shows an example of a schematic diagram of a production system 300 for performing oilfield production operations. As shown in the example of FIG. 3 , the production system 300 can include an oilfield network 302, an oilfield production tool 304, one or more data sources 306, one or more oilfield application(s) 308, and one or more plug-in(s) 310. As an example, the oilfield network 302 can be an interconnection of pipes (e.g., conduits) that connects wellsites (e.g., a wellsite 1 312, a wellsite n 314, etc.) to a processing facility 320. A pipe in the oilfield network 302 may be connected to a processing facility (e.g., a processing facility 320), a wellsite (e.g., the wellsite 1 312, the wellsite n 314, etc.), and/or a junction in which pipes are connected. As an example, flow rate of fluid and/or gas into pipes may be adjustable; thus, certain pipes in the oilfield network 302 may be choked or closed so as to not allow fluid and/or gas through the pipe. A pipe may be considered open (e.g., optionally choked) when the pipe allows for flow of fluid and/or gas. As to a choke, choking may allow for adjusting one or more characteristics of a piece of flow equipment (e.g., a cross-sectional flow area, etc.), for example, for adjusting to fully open flow, for adjusting to choked flow and/or for adjusting to no flow (e.g., closed).

As an example, a choke may include an orifice that is used to control fluid flow rate or downstream system pressure. As an example, a choke may be provided in any of a variety of configurations (e.g., for fixed and/or adjustable modes of operation). As an example, an adjustable choke may enable fluid flow and pressure parameters to be changed to suit process or production requirements. As an example, a fixed choke may be configured for resistance to erosion under prolonged operation or production of abrasive fluids.

The oilfield network 302 may be a gathering network and/or an injection network. A gathering network may be an oilfield network used to obtain hydrocarbons from a wellsite (e.g., the wellsite 1 312, the wellsite n 314, etc.). In a gathering network, hydrocarbons may flow from the wellsites to the processing facility 320. An injection network may be an oilfield network used to inject the wellsites with injection substances, such as water, carbon dioxide, and other chemicals that may be injected into the wellsites. In an injection network, the flow of the injection substance may flow towards the wellsite (e.g., toward the wellsite 1 312, the wellsite n 314, etc.).

The oilfield network 302 may also include one or more surface units (e.g., a surface unit 1 316, a surface unit n 318, etc.), for example, a surface unit for each wellsite. Such surface units may include functionality to collect data from sensors (see, e.g., the surface unit 216 of FIG. 2 ). Such sensors may include sensors for measuring flow rate, water cut, gas lift rate, pressure, and/or other such variables related to measuring and monitoring hydrocarbon production. As shown, the oilfield network 302 can include one or more transceivers 321, for example, to receive information, to transmit information, to receive information and transmit information, etc. As an example, information may be received and/or transmitted via wire and/or wirelessly. As an example, information may be received and/or transmitted via a communications network such as, for example, the Internet, the Cloud, a cellular network, a satellite network, etc.

As an example, the oilfield production tool 304 may be connected to the oilfield network 302. The oilfield production tool 304 may be a simulator (e.g., a simulation framework) or a plug-in for a simulator (e.g., or other application(s)). The oilfield production tool 304 may include one or more transceivers 322, a report generator 324, an oilfield modeler 326, and an oilfield analyzer 328. As an example, the one or more transceivers 322 may be configured to receive information, to transmit information, to receive information and transmit information, etc. As an example, information may be received and/or transmitted via wire and/or wirelessly. As an example, information may be received and/or transmitted via a communications network such as, for example, the Internet, the Cloud, a cellular network, a satellite network, etc.

As an example, one or more of the one or more transceivers 322 may include functionality to collect oilfield data. The oilfield data may be data from sensors, historical data, or any other such data. One or more of the one or more transceivers 322 may also include functionality to interact with a user and display data such as a production result.

As an example, the report generator 324 can include functionality to produce graphical and textual reports. Such reports may show historical oilfield data, production models, production results, sensor data, aggregated oilfield data, or any other such type of data.

As an example, the data repository 352 may be a storage unit and/or device (e.g., a file system, database, collection of tables, or any other storage mechanism) for storing data, such as the production results, sensor data, aggregated oilfield data, or any other such type of data. As an example, the data repository 352 may include multiple different storage units and/or hardware devices. Such multiple different storage units and/or devices may or may not be of the same type or located at the same physical site. As an example, the data repository 352, or a portion thereof, may be secured via one or more security protocols, whether physical, algorithmic or a combination thereof (e.g., data encryption, secure device access, secure communication, etc.).

In the example of FIG. 3 , the oilfield modeler 326 can include functionality to create a model of a wellbore and an oilfield network. As shown, the oilfield modeler 326 includes a wellbore modeler 360 and a network modeler 332. As an example, the wellbore modeler 360 can allow a user to create a graphical wellbore model or single branch model. As an example, a wellbore model can define operating parameters (e.g., actual, theoretical, etc.) of a wellbore (e.g., pressure, flow rate, etc.). As an example, a single branch model may define operating parameters of a single branch in an oilfield network.

As to the network modeler 332, it may allow a user to create a graphical network model that combines wellbore models and/or single branch models. As an example, the network modeler 328 and/or wellbore modeler 360 may model pipes in the oilfield network 302 as branches of the oilfield network 302 (e.g., optionally as one or more segments, optionally with one or more nodes, etc.). In such an example, each branch may be connected to a wellsite or a junction. A junction may be defined as a group of two or more pipes that intersect at a particular location (e.g., a junction may be a node or a type of node).

As an example, a modeled oilfield network may be formed as a combination of sub-networks. In such an example, a sub-network may be defined as a portion of an oilfield network. For example, a sub-network may be connected to the oilfield network 302 using at least one branch. Sub-networks may be a group of connected wellsites, branches, and junctions. As an example, sub-networks may be disjoint (e.g., branches and wellsites in one sub-network may not exist in another sub-network).

As an example, the oilfield analyzer 328 can include functionality to analyze the oilfield network 302 and generate a production result for the oilfield network 302. As shown in the example of FIG. 3 , the oilfield analyzer 328 may include one or more of the following: a production analyzer 334, a fluid modeler 336, a flow modeler 338, an equipment modeler 340, a single branch solver 342, a network solver 344, a Wegstein solver 348, a Newton solver 350, and an offline tool 346.

As an example, the production analyzer 334 can include functionality to receive a workflow request and interact with the single branch solver 342 and/or the network solver 344 based on particular aspects of the workflow. For example, the workflow may include a nodal analysis to analyze a wellsite or junction of branches, pressure and temperature profile, model calibration, gas lift design, gas lift optimization, network analysis, and other such workflows.

As an example, the fluid modeler 336 can include functionality to calculate fluid properties (e.g., phases present, densities, viscosities, etc.) using one or more compositional and/or black-oil fluid models. The fluid modeler 336 may include functionality to model oil, gas, water, hydrate, wax, and asphaltene phases. As an example, the flow modeler 338 can include functionality to calculate pressure drop in pipes (e.g., pipes, tubing, etc.) using industry standard multiphase flow correlations. As an example, the equipment modeler 340 can include functionality to calculate pressure changes in equipment pieces (e.g., chokes, pumps, compressors, etc.). As an example, one or more substances may be introduced via a network for purposes of managing asphaltenes, waxes, etc. As an example, a modeler may include functionality to model interaction between one or more substances and fluid (e.g., including material present in the fluid).

As an example, the single branch solver 342 may include functionality to calculate the flow and pressure drop in a wellbore or a single flowline branch given various inputs.

As an example, the network solver 344 can include functionality to calculate a flow rate and pressure drop throughout the oilfield network 302. The network solver 344 may be configured to connect to the offline tool 346, the Wegstein solver 348, and the Newton solver 350. As an example, alternatively or additionally, one or more other solvers may be provided, for example, consider a sequential linear programming solver (SLP), a sequential quadratic programming solver (SQP), etc. As an example, a solver may be part of the production tool 304, part of the analyzer 328 of the production tool 304, part of a system to which the production tool 304 may be operatively coupled, etc.

As an example, the offline tool 346 may include a wells offline tool and a branches offline tool. A wells offline tool may include functionality to generate a production model using the single branch solver 342 for a wellsite or branch. A branches offline tool may include functionality to generate a production model for a sub-network using the production model for a wellsite, a single branch, or a sub-network of the sub-network.

As an example, a production model may be capable of providing a description of a wellsite with respect to various operational conditions. A production model may include one or more production functions that may be combined, for example, where each production function may be a function of variables related to the production of hydrocarbons. For example, a production function may be a function of flow rate and/or pressure. Further, a production function may account for environmental conditions related to a sub-network of the oilfield network 302, such as changes in elevation (e.g., for gravity head, pressure, etc.), diameters of pipes, combination of pipes, and changes in pressure resulting from joining pipes. A production model may provide estimates of flow rate for a wellsite or sub-network of an oilfield network.

As an example, one or more separate production functions may exist that can account for changes in one or more values of an operational condition. An operational condition may identify a property of hydrocarbons or injection substance. For example, an operational condition may include a watercut (WC), reservoir pressure, gas lift rate, etc. Other operational conditions, variables, environmental conditions may be considered.

As to the network solver 344, in the example of FIG. 3 , it is shown as being connected to the Wegstein solver 348 and/or the Newton solver 350. The Wegstein solver 348 and the Newton solver 350 include functionality to combine a production model for several sub-networks to create a production result that may be used to plan an oilfield network, optimize flow rates of wellsites in an oilfield network, and/or identify and address faulty components within an oilfield network. The Wegstein solver 348 can use an iterative method with Wegstein acceleration.

An oilfield network may be solved by identifying pressure drop (e.g., pressure differential), for example, through use of momentum equations. As an example, an equation for pressure differential may account for factors such as fluid potential energy (e.g., hydrostatic pressure), friction (e.g., shear stress between conduit wall and fluid), and acceleration (e.g., change in fluid velocity). As an example, an equation may be expressed in terms of static reservoir pressure, a flowing bottom hole pressure and flowrate. As an example, equations may account for vertical, horizontal or angled arrangements of equipment. Various examples of equations may be found in a dynamic multiphase flow simulator such as the simulator of the OLGA™ simulation framework (Schlumberger Limited, Houston, TX), which may be implemented for design and diagnostic analysis of oil and gas production systems. As an example, a simulation framework may include one or more sets of instructions for building a model; for fluid and multiphase flow modeling; for reservoir, well and completion modeling; for field equipment modeling; and for operations (e.g., artificial lift, gas lift, wax prediction, nodal analysis, network analysis, field planning, multi-well analysis, etc.).

As an example, a system may implement equations that include dynamic conservation equations for momentum, mass and energy. As an example, pressure and momentum can be solved implicitly and simultaneously and, for example, conservation of mass and energy (e.g., temperature) may be solved in succeeding separate stages.

As an example, an equation for pressure differential can account for factors such as fluid potential energy (e.g., hydrostatic pressure), friction (e.g., shear stress between conduit wall and fluid), and acceleration (e.g., change in fluid velocity). In addition, as mentioned, equations can be used to consider dynamic aspects. For example, equations can account for time and forces to accelerate and decelerate fluid (e.g., and objects) inserted into multiphase flow (e.g., consider pigs, etc.). As an example, an approach may consider the time it takes to conserve mass and energy (e.g., an amount of time it takes to drain a system, pipeline, or vessel). As an example, an approach may consider ramp-up time for production, for example, from one production rate to another production rate, etc. As an example, an approach may consider time it takes before a first condensate appears at an outlet of a production network during startup, etc.

As an example, an equation for a pressure differential (e.g., ΔP) may be rearranged to solve for flow rate (e.g., Q), where the equation may include the Reynolds number (e.g., Re, a dimensionless ratio of inertial to viscous forces), one or more friction factors (e.g., which may depend on flow regime), etc.

Through use of equations for flow into and out of a branch and equating to zero, a linear matrix in unknown pressures may be obtained. As an example, fixed flow branches (i.e., branches in which the flow does not change) may be solved directly for the node pressures.

As an example, a method can include defining variables and residual equations as well as branches in an oilfield network that may include a number of equipment items. As an example, a branch may be divided into sub-branches with each sub-branch containing a single equipment item. As an example, a new node may be used to join each pair of sub-branches. In this example, primary Newton-Raphson variables can include a flow (Q_(ib)) in each sub-branch in the network and a pressure Pin at each node in the network. In this example, temperature (or enthalpy) and composition may be treated as secondary variables.

As an example, residual equations may include a branch residual, an internal node residual, and a boundary condition. In such an example, a branch residual for a sub-branch relates the branch flow to the pressure at the branch inlet node and the pressure at the outlet node. As an example, internal node residuals can define where total flow into a node is equal to total flow out of the node.

As an example, determining an initial solution may be performed using a production model where for each subsequent iteration, a Jacobian matrix is calculated. The values of the Jacobian matrix may be used to solve a Jacobian equation for the Newton-Raphson update. To solve the Jacobian equation, one or more types of matrix solvers may be used.

In the example of FIG. 3 , the one or more data sources 306 include one or more types of repositories for data. For example, the one or more data sources 306 may be Internet sources, sources from a company having ties to the oilfield network 302, or any other location in which data may be obtained. The data may include historical data, data collected from other oilfield networks, data collected from the oilfield network being modeled, data describing environmental or operational conditions.

In the example of FIG. 3 , the one or more oilfield applications 308 may be applications related to the production of hydrocarbons. The one or more oilfield applications 308 may include functionality to evaluate a formation, manage drilling operations, evaluate seismic data, evaluate workflows in the oilfield, perform simulations, or perform any other oilfield related function. In the example of FIG. 3 , the one or more plug-ins 310 may allow integration with packages such as, for example, a TUFPP model, an Infochem Multiflash model (Infochem Computer Services Ltd., London, UK), an equipment model, etc. (e.g., consider one or more simulators like HYSYS™ (AspenTech, Burlington, Massachusetts), UNISIM™ (Honeywell, Morristown, New Jersey), etc.).

While the example of FIG. 3 shows the oilfield production tool 304 as a separate component from the oilfield network 302, the oilfield production tool 304 may alternatively be part of the oilfield network 302. For example, the oilfield production tool 304 may be located at one of the wellsites (e.g., the wellsite 1 312, the wellsite n 314, etc.), at the processing facility 320, or any other location in the oilfield network 302. As another example, the oilfield production tool 304 may exist separate from the oilfield network 302, such as when the oilfield production tool 304 is used to plan the oilfield network.

Various types of numerical solution schemes may be characterized as being explicit or implicit. For example, when a direct computation of dependent variables can be made in terms of known quantities, a scheme may be characterized as explicit. Whereas, when dependent variables are defined by coupled sets of equations, and either a matrix or iterative technique is implemented to obtain a solution, a scheme may be characterized as implicit.

As an example, a scheme may be characterized as adaptive implicit (“AIM”). An AIM scheme may adapt, for example, based on one or more gradients as to one or more variables, properties, etc. of a model. For example, where a model of a subterranean environment includes a region where porosity varies rapidly with respect to one or more physical dimensions (e.g., x, y, or z), a solution for one or more variables in that region may be modeled using an implicit scheme while an overall solution for the model also includes an explicit scheme (e.g., for one or more other regions for the same one or more variables).

As an example, a scheme may be implemented as part of the ECLIPSE™ 300 reservoir simulator marketed by Schlumberger Ltd. (Houston, Texas). As an example, the aforementioned OLGA™ simulator may include an interface that allows for interoperability with an ECLIPSE™ simulator. The ECLIPSE™ 300 reservoir simulator may implement a fully implicit scheme or an implicit-explicit scheme that is implicit in pressure and explicit in saturation, known as IMPES. In the fully implicit scheme, values for both pressure and saturation are provided at the end of each simulation time-step; whereas the IMPES scheme uses saturation values from the beginning of the time-step to solve for pressure values at the end of the time-step. In such examples, a reservoir simulator iterates until pressures values in grid blocks of a model of the reservoir being simulated have reached some internally consistent solution. However, a solution may be difficult to find if saturation (which the IMPES scheme assumes is constant within a time-step) changes rapidly during that time-step (e.g., a large percentage change in grid block values for saturation). The IMPES scheme may be able to cope with such an issue by decreasing “length” (e.g., duration) of the time-step but at the cost of more time-steps (e.g., in an effort to achieve a more stable solution).

The aforementioned fully implicit scheme may be a more stable option with saturation and pressure being obtained simultaneously so as any difference between their values for one time-step and a next time-step will not disturb a solution process as much as when compared to the IMPES scheme. Thus, in a fully implicit scheme, the “length” (e.g., duration) of a time-step may be larger but it also means that the fully implicit scheme may take additional processing time to achieve solutions (e.g., in comparison with an IMPES scheme). However, in a reservoir where properties change rapidly, a fully implicit scheme may provide a solution in less computational time than an IMPES scheme, even though an iteration of the fully implicit scheme may take longer to complete when compared to an iteration of the IMPES scheme.

The aforementioned ECLIPSE™ 300 reservoir simulator may also implement one or more components such as a black-oil simulator component, a compositional simulator component, or a thermal simulator component (e.g., for simulating thermodynamics, etc.). As an example, a black-oil simulator component may include equations to model three fluid phases (e.g., oil, water, and gas, with gas dissolving in oil and oil vaporizing in gas); as an example, a compositional simulator component may include equations to model phase behavior and compositional changes; and, as an example, a thermal simulator component may include instructions (e.g., for equations, etc.) to model a thermal recovery processes such as steam-assisted gravity drainage (SAGD), cyclic stream operations, in-situ combustion, heater, and cold heavy oil production with sand. As an example, one or more thermal components may provide instructions for modeling and simulating multiple hydrocarbon components in both oil and gas phases, a single nonvolatile component in an oil phase, oil, gas, water, and solids behaviors (e.g., optionally with chemical reactions), well production rates based on factors such as well temperature, low-temperature thermal scenarios (e.g., experiments or cold heavy oil production with sand), toe-to-heel air injection scenarios, foamy oil (e.g., as to effect on gas production, gas drive, oil production, etc.), multi-segmented well models (e.g., optionally including dual-tubing, horizontal wells, multiphase flow effects in a wellbore, etc.).

As to network models, as an example, a method can include simulation of dynamic and/or steady state operation of an oil and gas production system over various ranges of operating conditions and configurations. In such an example, the method may include an implicit evaluation of conservation of energy equations in addition to mass and momentum as an effective technique for efficiently and robustly simulating the production system where, for example, the production system includes fluid such as heavy oil, steam, or other fluids at or near critical pressures or temperatures. The term “critical point” is sometimes used herein to specifically denote a vapor-liquid critical point of a material, above which distinct liquid and gas phases do not exist.

As mentioned, a production system can provide for transportation of oil and gas fluids from well locations along flowlines which are interconnected at junctions to combine fluids from many wells for delivery to a processing facility. Along these flowlines (including at one or more ends of a flowline), production equipment may be inserted to modify the flowing characteristics like flow rate, pressure, composition, and temperature. As an example, a boundary condition may depend on a type of equipment, operation of a piece of equipment, etc.

As an example, a simulation may be performed using one type of equipment along a flowline and another simulation may be performed using another type of equipment along the same flowline, for example, to determine which type of equipment may be selected for installation in a production system.

As an example, a simulation may be performed using one type of equipment at a position (e.g., with respect to a flowline) and another simulation may be performed using another type of equipment at a different position (e.g., with respect to the same flowline or a different flowline), for example, to determine which type of equipment may be selected for installation in a production system as well as to determine where a type of equipment may be installed. As an example, a simulation may be performed using one type of equipment at a position (e.g., with respect to a flowline) and another simulation may be performed using that type of equipment at a different position (e.g., with respect to the same flowline or a different flowline), for example, to determine where that type of equipment may be installed.

FIG. 4 shows an example of a relatively small production system network 410 (e.g., optionally a portion of a larger network 401), an example of a system 450 and examples of instructions 470. As shown, the network 410 forms somewhat of a tree like structure where flowlines represent branches (e.g., segments) and junctions represent nodes. As shown in FIG. 4 , the network 410 provides for transportation of oil and gas fluids from well locations along flowlines interconnected at junctions with final delivery at a central processing facility.

In the example of FIG. 4 , various portions of the network 410 may include a conduit. For example, consider a perspective view of a geologic environment 403 that includes two conduits which may be a conduit to Man1 and a conduit to Man3 in the network 410. The conduits may be specified at various points by characteristics, which may be characteristics of the environment, characteristics of the conduits, characteristics of fluid in the conduits, etc. For example, consider conduit elevation, which may allow for determination of conduit inclination. As an example, consider conduit cross-sectional flow area, which may be defined by one or more parameters such as, for example, a conduit diameter. As an example, consider fluid that may flow in a conduit where the fluid may be characterized at least in part by a property such as, for example, viscosity (see, e.g., the ternary diagram 250 and the table 260 of FIG. 2 and approaches to multiphase properties, etc.). As an example, thermal conditions may optionally be considered such as, for example, latent heat, heat transfer, etc. As an example, thermal conditions may depend on insulation of equipment, temperature of an environment, wind, sun, rain, snow, etc. Such factors may be considered when assessing an existing network, developing a network, extending a network, etc.

As an example, given information of operating condition(s) at boundary nodes (e.g., where fluid enters and exists the system) and the physical environment between them (e.g., geographical location, elevation, ambient temperature, etc.), a production engineer may aim to design a production system that meets business and regulatory requirements constrained to operating limits of available equipment.

As an example, a method can include implementing one or more components to simulate steady state operation of a production system, for example, as including a network (e.g., as a sub-network, etc.) as in the example of FIG. 4 (also see, e.g., FIG. 1 ). Such a method may include simulating the steady state operation over a selected range of operating conditions and configurations (e.g., optionally a broadest reasonable range).

As explained, a production system may provide for transportation of oil and gas fluids from well locations to a processing facility and can represent a substantial investment in infrastructure with both economic and environmental impact. Simulation of such a system, which may include hundreds or thousands of flow lines and production equipment interconnected at junctions to form a network, can be complex and involve multiphase flow science and engineering and mathematical methods to provide solutions (e.g., by solving large systems of non-linear equations). Factors associated with solid formation, corrosion and erosion, and environmental impact may increase complexity and cost.

As an example, a method can include formulating a proxy (e.g., or surrogate) model that may be suitable for expediting network analysis. Such a method may, for example, be implemented via a computing system.

As shown in FIG. 4 , the example system 450 includes one or more information storage devices 452, one or more computers 454, one or more networks 460 and instructions 470 (e.g., organized as one or more sets of instructions). As to the one or more computers 454, each computer may include one or more processors (e.g., or processing cores) 456 and memory 458 for storing the instructions 470 (e.g., one or more sets of instructions), for example, executable by at least one of the one or more processors. As an example, a computer may include one or more network interfaces (e.g., wired, or wireless), one or more graphics cards, a display interface (e.g., wired, or wireless), etc. As an example, imagery such as surface imagery (e.g., satellite, geological, geophysical, etc.) may be stored, processed, communicated, etc. As an example, data may include SAR data, GPS data, etc. and may be stored, for example, in one or more of the storage devices 452. As an example, information that may be stored in one or more of the storage devices 452 may include information about equipment, location of equipment, orientation of equipment, fluid characteristics, etc.

As an example, the instructions 470 can include instructions (e.g., stored in the memory 458) executable by at least one of the one or more processors 456 to instruct the system 450 to perform various actions. As an example, the system 450 may be configured such that the instructions 470 provide for establishing a framework, for example, that can perform network modeling. As an example, one or more methods, techniques, etc. may be performed using one or more sets of instructions, which may be, for example, the instructions 470 of FIG. 4 .

FIG. 4 shows examples of the instructions 470 as including a graphical user interface (GUI) component 471, a map component 472, an equipment component 473, a data component 474 (e.g., for measured data, synthetic data, etc.), a modeling component 475, and one or more other components 476 where a component can be or include a set of instructions.

As an example, a component can include instructions to instruct a system to render terrain and equipment locations to a display (e.g., via the GUI component 471, the map component 472, the equipment component 473, etc.); receive data for at least a portion of a network (e.g., via the data component 474); analyze the data with respect to a model associated with the terrain and the equipment locations (e.g., via the modeling component 475); and render information to the display based at least in part on an analysis (e.g., via the GUI component 471, a report component, etc.).

As an example, a framework may be implemented using various features of a system such as, for example, the system 450 of FIG. 4 . As an example, one or more sets of instructions may be provided that include instructions that may be executed by a processor or processors. As an example, instructions may be provided for execution of instructions in parallel, for example, to consider multiple features of a network or networks that may be associated with a geologic environment such as the geologic environment 110 of FIG. 1 .

Production systems for oil and gas often cover multiple wells tied back to a manifold, platform or onshore, etc. (e.g., consider a sub-sea manifold, a wellhead platform, a land-based manifold, etc.). At a manifold or wellhead platform, production from different wells may be co-mingled (e.g., merged, mixed, etc.) and fed to one or more multiphase pipelines that can transport fluid, for example, to topside or central processing facilities. As an example, multiple manifolds and wellhead platforms may feed one topside/central processing facility. As an example, produced fluid from a topside/central processing facility may again be fed to export pipelines for gas and/or oil to feed a market or a chemical processing plant.

As an example, a fluid production network can include a substantially vertical conduit and a substantially horizontal conduit and/or a substantially vertical conduit and/or a conduit that is neither substantially horizontal nor substantially vertical. As an example, a substantially vertical conduit can be oriented at an angle with respect to horizontal that is greater than about 50 degrees. As an example, a substantially horizontal conduit can be oriented at an angle with respect to horizontal that is less than about 40 degrees (e.g., between −40 degrees and +40 degrees depending on whether sloping down or up with respect to a direction, which may be a flow direction). As an example, a model or models can account for orientation, for example, as one or more parameters of a model or models.

As an example, a fluid production network can be or include a multiphase fluid production network. As an example, values output via a model-based framework can include values for fluid flow variables at a plurality of different times (e.g., single phase, multiphase, etc.).

As an example, a system and/or a method may optionally implement one or more Object Linking and Embedding (OLE) for Process Control (OPC) features (e.g., components, standards, etc.). For example, an OPC server may operate in conjunction with one or more OPC clients for transfer of information. OLE for Process Control (OPC) can include one or more types of data transportation technologies, which may include one or more technologies other than OLE (e.g., .NET™ framework, XML, binary-encoded TCP format, etc.).

As an example, one or more industrial information technology (IT) platforms that may include OPC Data Access (DA) functionality can be used to connect to one or more sensors or pieces of equipment, for example, through OPC and/or OPC UA as well as one or more standards such as, for example, MODBUS, WITSML, etc.

As an example, a framework may be optionally coupled to one or more data transmission systems, which may include, for example, a supervisory control and data acquisition (SCADA) system. For example, a framework may provide for monitoring a production system using one or more models where, responsive to model-based results, one or more notifications (e.g., instructions, commands, alarms, etc.) may be communicated via one or more data transmission systems. As an example, a SCADA system can include equipment for monitoring and control, which may operate, for example, with coded signals over communication channels (e.g., a communication channel per remote station, etc.).

As an example, a scheduler and associated components may be run with respect to a framework or frameworks. For example, consider a modeling framework that allows for building of models. As an example, information may be exchanged between frameworks, between components, etc.

FIG. 5 shows an example of a system 500 that includes a workspace framework 510 that can provide for instantiation of, rendering of, interactions with, etc., a graphical user interface (GUI) 520. In the example of FIG. 5 , the GUI 520 can include graphical controls for computational frameworks (e.g., applications) 521, projects 522, visualization 523, one or more other features 524, data access 525, and data storage 526.

In the example of FIG. 5 , the workspace framework 510 may be tailored to a particular geologic environment such as an example geologic environment 550. For example, the geologic environment 550 may include layers (e.g., stratification) that include a reservoir 551 and that may be intersected by a fault 553. As an example, the geologic environment 550 may be outfitted with a variety of sensors, detectors, actuators, etc. For example, equipment 552 may include communication circuitry to receive and to transmit information with respect to one or more networks 555. Such information may include information associated with downhole equipment 554, which may be equipment to acquire information, to assist with resource recovery, etc. Other equipment 556 may be located remote from a wellsite and include sensing, detecting, emitting or other circuitry. Such equipment may include storage and communication circuitry to store and to communicate data, instructions, etc. As an example, one or more satellites may be provided for purposes of communications, data acquisition, etc. For example, FIG. 5 shows a satellite in communication with the network 555 that may be configured for communications, noting that the satellite may additionally or alternatively include circuitry for imagery (e.g., spatial, spectral, temporal, radiometric, etc.).

FIG. 5 also shows the geologic environment 550 as optionally including equipment 557 and 558 associated with a well that includes a substantially horizontal portion that may intersect with one or more fractures 559. For example, consider a well in a shale formation that may include natural fractures, artificial fractures (e.g., hydraulic fractures) or a combination of natural and artificial fractures. As an example, a well may be drilled for a reservoir that is laterally extensive. In such an example, lateral variations in properties, stresses, etc. may exist where an assessment of such variations may assist with planning, operations, etc. to develop a laterally extensive reservoir (e.g., via fracturing, injecting, extracting, etc.). As an example, the equipment 557 and/or 558 may include components, a system, systems, etc. for fracturing, seismic sensing, analysis of seismic data, assessment of one or more fractures, etc.

In the example of FIG. 5 , the GUI 520 shows some examples of computational frameworks, which may include, for example, one or more of the DRILLPLAN, PETREL, TECHLOG, PIPESIM, PETROMOD, ECLIPSE, OLGA, and INTERSECT frameworks (Schlumberger Limited, Houston, Texas).

The DRILLPLAN framework provides for digital well construction planning and includes features for automation of repetitive tasks and validation workflows, enabling improved quality drilling programs (e.g., digital drilling plans, etc.) to be produced quickly with assured coherency.

The PETREL framework can be part of the DELFI cognitive E&P environment (Schlumberger Limited, Houston, Texas) for utilization in geosciences and geoengineering, for example, to analyze subsurface data from exploration to production of fluid from a reservoir.

The TECHLOG framework can handle and process field and laboratory data for a variety of geologic environments (e.g., deepwater exploration, shale, etc.). The TECHLOG framework can structure wellbore data for analyses, planning, etc.

The PETROMOD framework provides petroleum systems modeling capabilities that can combine one or more of seismic, well, and geological information to model the evolution of a sedimentary basin. The PETROMOD framework can predict if, and how, a reservoir has been charged with hydrocarbons, including the source and timing of hydrocarbon generation, migration routes, quantities, and hydrocarbon type in the subsurface or at surface conditions.

The ECLIPSE framework provides a reservoir simulator (e.g., as a computational framework) with numerical solutions for fast and accurate prediction of dynamic behavior for various types of reservoirs and development schemes.

The INTERSECT framework provides a high-resolution reservoir simulator for simulation of detailed geological features and quantification of uncertainties, for example, by creating accurate production scenarios and, with the integration of precise models of the surface facilities and field operations, the INTERSECT framework can produce reliable results, which may be continuously updated by real-time data exchanges (e.g., from one or more types of data acquisition equipment in the field that can acquire data during one or more types of field operations, etc.). The INTERSECT framework can provide completion configurations for complex wells where such configurations can be built in the field, can provide detailed chemical-enhanced-oil-recovery (EOR) formulations where such formulations can be implemented in the field, can analyze application of steam injection and other thermal FOR techniques for implementation in the field, advanced production controls in terms of reservoir coupling and flexible field management, and flexibility to script customized solutions for improved modeling and field management control. The INTERSECT framework, as with the other example frameworks, may be utilized as part of the DELFI cognitive E&P environment, for example, for rapid simulation of multiple concurrent cases. For example, a workflow may utilize one or more of the DELFI on demand reservoir simulation features.

The aforementioned DELFI environment provides various features for workflows as to subsurface analysis, planning, construction, and production, for example, as illustrated in the workspace framework 510. As shown in FIG. 5 , outputs from the workspace framework 510 can be utilized for directing, controlling, etc., one or more processes in the geologic environment 550 and, feedback 560, can be received via one or more interfaces in one or more forms (e.g., acquired data as to operational conditions, equipment conditions, environment conditions, etc.).

As an example, a workflow may progress to a geology and geophysics (“G&G”) service provider, which may generate a well trajectory, which may involve execution of one or more G&G software packages. Examples of such software packages include the PETREL framework. As an example, a system or systems may utilize a framework such as the DELFI framework (Schlumberger Limited, Houston, Texas). Such a framework may operatively couple various other frameworks to provide for a multi-framework workspace. As an example, the GUI 520 of FIG. 5 may be a GUI of the DELFI framework.

In the example of FIG. 5 , the visualization features 523 may be implemented via the workspace framework 510, for example, to perform tasks as associated with one or more of subsurface regions, planning operations, constructing wells and/or surface fluid networks, and producing from a reservoir.

As an example, a visualization process can implement one or more of various features that can be suitable for one or more web applications. For example, a template may involve use of the JAVASCRIPT object notation format (JSON) and/or one or more other languages/formats. As an example, a framework may include one or more converters. For example, consider a JSON to PYTHON converter and/or a PYTHON to JSON converter. In such an example, one or more frameworks, APIs, sets of instructions may be utilized (e.g., via appropriate conversion, etc.).

As an example, visualization features can provide for visualization of various earth models, properties, etc., in one or more dimensions. As an example, visualization features can provide for rendering of information in multiple dimensions, which may optionally include multiple resolution rendering. In such an example, information being rendered may be associated with one or more frameworks and/or one or more data stores. As an example, visualization features may include one or more control features for control of equipment, which can include, for example, field equipment that can perform one or more field operations. As an example, a workflow may utilize one or more frameworks to generate information that can be utilized to control one or more types of field equipment (e.g., drilling equipment, wireline equipment, fracturing equipment, etc.).

As to a reservoir model that may be suitable for utilization by a simulator, consider acquisition of seismic data as acquired via reflection seismology, which finds use in geophysics, for example, to estimate properties of subsurface formations. As an example, reflection seismology may provide seismic data representing waves of elastic energy (e.g., as transmitted by P-waves and S-waves, in a frequency range of approximately 1 Hz to approximately 100 Hz). Seismic data may be processed and interpreted, for example, to understand better composition, fluid content, extent, and geometry of subsurface rocks. Such interpretation results can be utilized to plan, simulate, perform, etc., one or more operations for production of fluid from a reservoir (e.g., reservoir rock, etc.).

Field acquisition equipment may be utilized to acquire seismic data, which may be in the form of traces where a trace can include values organized with respect to time and/or depth (e.g., consider 1D, 2D, 3D or 4D seismic data). For example, consider acquisition equipment that acquires digital samples at a rate of one sample per approximately 4 ms. Given a speed of sound in a medium or media, a sample rate may be converted to an approximate distance. For example, the speed of sound in rock may be on the order of around 5 km per second. Thus, a sample time spacing of approximately 4 ms would correspond to a sample “depth” spacing of about 10 meters (e.g., assuming a path length from source to boundary and boundary to sensor). As an example, a trace may be about 4 seconds in duration; thus, for a sampling rate of one sample at about 4 ms intervals, such a trace would include about 1000 samples where later acquired samples correspond to deeper reflection boundaries. If the 4 second trace duration of the foregoing example is divided by two (e.g., to account for reflection), for a vertically aligned source and sensor, a deepest boundary depth may be estimated to be about 10 km (e.g., assuming a speed of sound of about 5 km per second).

As an example, a model may be a simulated version of a geologic environment. As an example, a simulator may include features for simulating physical phenomena in a geologic environment based at least in part on a model or models. A simulator, such as a reservoir simulator, can simulate fluid flow in a geologic environment based at least in part on a model that can be generated via a framework that receives seismic data. A simulator can be a computerized system (e.g., a computing system) that can execute instructions using one or more processors to solve a system of equations that describe physical phenomena subject to various constraints. In such an example, the system of equations may be spatially defined (e.g., numerically discretized) according to a spatial model that includes layers of rock, geobodies, etc., that have corresponding positions that can be based on interpretation of seismic and/or other data. A spatial model may be a cell-based model where cells are defined by a grid (e.g., a mesh). A cell in a cell-based model can represent a physical area or volume in a geologic environment where the cell can be assigned physical properties (e.g., permeability, fluid properties, etc.) that may be germane to one or more physical phenomena (e.g., fluid volume, fluid flow, pressure, etc.). A reservoir simulation model can be a spatial model that may be cell-based.

A simulator can be utilized to simulate the exploitation of a real reservoir, for example, to examine different production scenarios to find an optimal one before production or further production occurs. A reservoir simulator does not provide an exact replica of flow in and production from a reservoir at least in part because the description of the reservoir and the boundary conditions for the equations for flow in a porous rock are generally known with an amount of uncertainty. Certain types of physical phenomena occur at a spatial scale that can be relatively small compared to size of a field. A balance can be struck between model scale and computational resources that results in model cell sizes being of the order of meters; rather than a lesser size (e.g., a level of detail of pores). A modeling and simulation workflow for multiphase flow in porous media (e.g., reservoir rock, etc.) can include generalizing real micro-scale data from macro scale observations (e.g., seismic data and well data) and upscaling to a manageable scale and problem size. Uncertainties can exist in input data and solution procedure such that simulation results too are to some extent uncertain. A process known as history matching can involve comparing simulation results to actual field data acquired during production of fluid from a field. Information gleaned from history matching, can provide for adjustments to a model, data, etc., which can help to increase accuracy of simulation.

As an example, a simulator may utilize various types of constructs, which may be referred to as entities. Entities may include earth entities or geological objects such as wells, surfaces, reservoirs, etc. Entities can include virtual representations of actual physical entities that may be reconstructed for purposes of simulation. Entities may include entities based on data acquired via sensing, observation, etc. (e.g., consider entities based at least in part on seismic data and/or other information). As an example, an entity may be characterized by one or more properties (e.g., a geometrical pillar grid entity of an earth model may be characterized by a porosity property, etc.). Such properties may represent one or more measurements (e.g., acquired data), calculations, etc.

As an example, a simulator may utilize an object-based software framework, which may include entities based on pre-defined classes to facilitate modeling and simulation. As an example, an object class can encapsulate reusable code and associated data structures. Object classes can be used to instantiate object instances for use by a program, script, etc. For example, borehole classes may define objects for representing boreholes based on well data. A model of a basin, a reservoir, etc. may include one or more boreholes where a borehole may be, for example, for measurements, injection, production, etc. As an example, a borehole may be a wellbore of a well, which may be a completed well (e.g., for production of a resource from a reservoir, for injection of material, etc.).

While several simulators are illustrated in the example of FIG. 5 , one or more other simulators may be utilized, additionally or alternatively. For example, consider the VISAGE geomechanics simulator (Schlumberger Limited, Houston Texas) or the PIPESIM network simulator (Schlumberger Limited, Houston Texas), etc. The VISAGE simulator includes finite element numerical solvers that may provide simulation results such as, for example, results as to compaction and subsidence of a geologic environment, well and completion integrity in a geologic environment, cap-rock and fault-seal integrity in a geologic environment, fracture behavior in a geologic environment, thermal recovery in a geologic environment, CO₂ disposal, etc. The PIPESIM simulator includes solvers that may provide simulation results such as, for example, multiphase flow results (e.g., from a reservoir to a wellhead and beyond, etc.), flowline and surface facility performance, etc. As an example, a reservoir or reservoirs may be simulated with respect to one or more enhanced recovery techniques (e.g., consider a thermal process such as steam-assisted gravity drainage (SAGD), etc.). As an example, the PIPESIM simulator may be an optimizer that can optimize one or more operational scenarios at least in part via simulation of physical phenomena. The MANGROVE simulator (Schlumberger Limited, Houston, Texas) provides for optimization of stimulation design (e.g., stimulation treatment operations such as hydraulic fracturing) in a reservoir-centric environment. The MANGROVE framework can combine scientific and experimental work to predict geomechanical propagation of hydraulic fractures, reactivation of natural fractures, etc., along with production forecasts within 3D reservoir models (e.g., production from a drainage area of a reservoir where fluid moves via one or more types of fractures to a well and/or from a well). The MANGROVE framework can provide results pertaining to heterogeneous interactions between hydraulic and natural fracture networks, which may assist with optimization of the number and location of fracture treatment stages (e.g., stimulation treatment(s)), for example, to increased perforation efficiency and recovery.

The PETREL framework provides components that allow for optimization of exploration and development operations. The PETREL framework includes seismic to simulation software components that can output information for use in increasing reservoir performance, for example, by improving asset team productivity. Through use of such a framework, various professionals (e.g., geophysicists, geologists, and reservoir engineers) can develop collaborative workflows and integrate operations to streamline processes (e.g., with respect to one or more geologic environments, etc.). Such a framework may be considered an application (e.g., executable using one or more devices) and may be considered a data-driven application (e.g., where data is input for purposes of modeling, simulating, etc.).

As mentioned, a framework may be implemented within or in a manner operatively coupled to the DELFI cognitive exploration and production (E&P) environment (Schlumberger, Houston, Texas), which is a secure, cognitive, cloud-based collaborative environment that integrates data and workflows with digital technologies, such as artificial intelligence and machine learning. As an example, such an environment can provide for operations that involve one or more frameworks. The DELFI environment may be referred to as the DELFI framework, which may be a framework of frameworks. As an example, the DELFI framework can include various other frameworks, which can include, for example, one or more types of models (e.g., simulation models, etc.).

FIG. 6 shows an example of a method 600 that includes a reception block 610 for receiving real time data where the real time data include at least pressure sensor data from multiple pressure sensors of a hydrocarbon fluid production network for multiple locations in the hydrocarbon fluid production network; a generation block 620 for generating an expected operational region in a multidimensional domain using at least a portion of the real time data; an operation block 630 for operating a leak detection system using the expected operational region; a tracking block 640 for tracking at least a portion of the real time data in the multidimensional domain; and an issuance block 650 for issuing a leak detection signal responsive to the tracking indicating an excursion from the expected operational region, where the leak detection signal indicates the presence of a leak in the hydrocarbon fluid production network.

The method 600 is shown in FIG. 6 in association with various computer-readable media (CRM) blocks 611, 621, 631, 641 and 651. Such blocks generally include instructions suitable for execution by one or more processors (or processor cores) to instruct a computing device or system to perform one or more actions. While various blocks are shown, a single medium may be configured with instructions to allow for, at least in part, performance of various actions of the method 600. As an example, a computer-readable medium (CRM) may be a computer-readable storage medium that is non-transitory and that is not a carrier wave. As an example, one or more of the blocks 611, 621, 631, 641 and 651 may be in the form of processor-executable instructions, for example, consider the one or more sets of instructions 470 of the system 450 of FIG. 4 , etc.

As an example, the method 600 may include generating an expected operational region using a simulator or simulators and, for example, updating the expected operational region dynamically using at least a portion of the real time data.

As an example, a method can include analyzing one or more changes to a system such as, for example, a change that is responsive to introduction of a chemical, water, etc. For example, consider a change due to introduction of an emulsifier, which may reduce viscosity of fluid in a system. As an example, a change in viscosity may cause a change in pressure drop (e.g., frictional forces, etc.), which may be trackable using pressure sensor data.

As an example, due to one or more factors, a production network may leak. As a production network may span some distance, which may be remote from people, a leak may not be readily detectable. As an example, a framework can provide for leak detection using various data and, for example, one or more models. Data can include, for example, pressure, flow, temperature, etc. As an example, upon detection of a leak or some probability of a leak, one or more actions may be taken to mitigate leakage of fluid or fluids. Such action can depend on locating a source of the leak or sources of leaks. Humans may use, for example, sight, smell, and sound. For example, discolored vegetation that is otherwise green along a pipeline right-of-way, or a pool of fluid along a pipeline right-of-way, or a cloud of vapor or mist along a pipeline right-of-way may be indications of leaks.

As an example, a framework may optionally issue one or more commands, instructions, alarms, etc., based at least in part on execution of a leak detection method. As an example, a command may be for a person to travel to a site, a drone to travel to a site (e.g., for data gathering, image gathering, etc.), etc. As an example, a drone may be an air-borne drone, a land drone, a sea drone, etc. As an example, a system can include a user interface for control of a drone and/or for data acquisition by one or more sensors of a drone (e.g., a camera, a microphone, etc.).

As an example, a Leak Detection System (LDS) may be based at least in part on a flow simulator. For example, consider an LDS based on the OLGA multiphase dynamic flow simulator and hosted in the OLGA online real-time architecture (e.g., OLGA framework, etc.).

An LDS can help to provide operational support by detecting a pipeline leak and estimating the location of a leak. As an example, an LDS may support operators in various activities.

As an example, an LDS may run one or more OLGA models which are first principles mathematical representations of the physical production system installation. As an example, an LDS may utilize field-measured values of pressure and flow and compare them to OLGA model-calculated values to determine the existence of pipeline leaks. As an example, once a leak has been detected, an LDS may provide estimates of the leak location.

As an example, an LDS may provide for detection of leaks as to one or more types of pipelines (e.g., consider a scenario of an Oil Pipeline and a Gas Pipeline from Station X to a Resource Processing Facility (RPF) and a Fuel Gas Pipeline from the RPF to Station X).

As to leak detection, one or more leak detection models may be utilized per pipeline for an LDS. For example, consider the following two models as examples: Flow—Pressure (FP) and Pressure—Flow (PF). Such detection models, FP and PF, can utilize simulator models (e.g., OLGA models) where the models can differ as to boundary conditions that are applied. For example, a simulator model may be adaptable to different boundary conditions where one set of boundary conditions is provided for an FP detection model and another set of boundary conditions is provided for a PF detection model. As an example, more than one model may be implemented for a pipeline. As an example, a single model may be selected for a pipeline.

As an example, a method can include receiving equipment information where the equipment information may include operational data for at least one piece of equipment of a hydrocarbon fluid production network. For example, consider a pump as a piece of equipment where operational data for the pump can include pump speed data, pump power data, pump temperature data, pump pressure data, pump operational state data, pump vibration data, etc. In such an example, detection of a leak, information about a leak, information about the fluid production network, information about one or more environmental conditions, information about one or more supply conditions (e.g., power supply, etc.) may be determined at least in part based on the equipment information. For example, where a pump speed is fluctuating or otherwise changing, such fluctuations may be due to an increase presence of gas in liquid (e.g., gas fraction), may be due to an unstable power supply (e.g., whether electrical from a utility, from a gas turbine electrical generator, etc.) and/or due to one or more effects of a leak or leaks (e.g., consider a leak at or proximate to a pump). A model-based framework can include one or more model equipment parameters that may couple equipment information with pressure, flow and/or temperature information about fluid in a fluid production network.

As an example, a method can include outputting a location of a fluid leak in a hydrocarbon fluid production network via a network interface of a computing system. In such an example, the method can include receiving the location via a network interface of a device where the device may be, for example, a mobile device (e.g., a smartphone, a GPS device, a drone, a vehicle, etc.). For example, consider a method that transmits a location of a fluid leak of a fluid production network to a drone or a drone controller such that the drone can travel to the location. In such an example, once underway to the location, the drone may receive a refined location as a leak detection system progresses in its leak location determination accuracy with respect to time (e.g., where the fluid production network stabilizes to a new steady state, etc.).

As an example, a framework may provide for one or more automatic shutdown actions. For example, a framework may be configured in the field as part of a Process Control System (PCS) that can respond at least in part to leak alarms generated by one or more LDSs.

As an example, a framework can include input data validation. For example, field measured data, such as pressures, temperatures, and flow rates, can be subjected to a data validation process where integrity of the data is determined (e.g., according to one or more integrity metrics). As an example, a data validation process or processes can perform one or more of the following health checks: OPC Quality, as a check of the health of a connection to field data (e.g., a connection to a SCADA OPC server, DCS OPC server, Process Information (PI) Historian (OSIsoft, LLC, San Leandro, California, USA), etc.); watchdog, as a check to determine whether updated values are coming through (e.g., if a value is static for too long, an alarm can be raised); range, as a check to determine if a value from the field is within a defined minimum range and/or a defined maximum range; and rate of change, as a check for rapid changes (e.g., and/or spikes) in field measured data.

FIG. 7 shows an example of a field 700 that includes various types of equipment that may be part of a fluid production network. In the example of FIG. 7 , the field includes a hub 704 and a resource processing facility (RPF) 708 as well as pipelines 722, 724 and 726 that can carry fluid(s) therebetween. Such fluid or fluids may be produced and/or transported to one or more sites 721, 723, 725, 752-1, 752-2, 752-3, 752-4, 752-5 and 752-6, which may be at surface and/or subsurface (e.g., subterranean). As an example, a pipeline may be a surface, subsurface or underwater pipeline and/or include one or more portions that may be at a surface location, at a subsurface location or at an underwater location.

In the example of FIG. 7 , the hub 704 may provide for production and/or separating oil and gas and for delivering one or more fluids to the RPF 708. As an example, a fluid production network can be operatively coupled to or include equipment for dehydrating, injecting, etc. In the example of FIG. 7 , the pipelines 722, 724 and 726 may be, for purposes of context, approximately 100 km. As to some examples of production of fluid(s), consider one or more production rates (e.g., flow rates) that may be in a range from about 1,000 m³/d to more than 100,000 m³/d; noting that under a shutdown condition, a rate may be approximately 0.

As an example, an LDS may provide for leak detection in a fuel gas pipeline (fuel gas pipeline operating in single phase); an oil pipeline (e.g., oil flowing through the oil pipeline being semi-stabilized where small amounts of gas can evaporate during shutdowns, but during flowing conditions, no gas evaporation may be expected; hence, it can be expected that an assumption as to the approach illustrated in FIG. 9 may hold; noting that such an assumption may also hold for small amounts of gas present in an oil pipeline); a gas pipeline (e.g., the gas pipeline including some amount of liquid and experiencing multiphase behavior to a large extent where it has been observed, that at low flow rates, the pipeline may be exposed to terrain induced slugging where it may be likely that the accuracy of the location estimate may be reduced at lower flow rates; whereas, at normal and high flow rates, the pipeline remains largely in friction dominated operation and an assumption as to the approach may hold).

As an example, flow rates, in terms of fluid velocity, may be of the order of meters per second (e.g., for a pipeline of about 28 inches in diameter or, for example, about 24 inches to about 30 inches in diameter (e.g., 61 cm to 76 cm); noting that other size pipelines may be considered). As an example, consider the following fluid velocities in pipelines as examples: gas: <8 m/s and oil: <2.5 m/s (e.g., about a 28-inch diameter pipeline (e.g., 71 cm), etc.).

FIG. 8 shows an example of a system architecture 800 that includes various components such as a field data component 810, a browser application component 820 (e.g., for mobile, desktop, workstation, etc.), a server hosting component 838 that hosts a simulator online architecture 834, which includes a real-time framework 850 for leak detection and/or leak location estimation, a web/network services component 860, a database component 872, a simulator component 874 (e.g., OLGA, or other(s)), an advisor framework 876 and a visualization framework 878. As shown, the server hosting component 838 is operatively coupled to the field data component 810 such that the real-time framework 850 can receive field data as input (e.g., via one or more interfaces) and can transmit simulator online output, which may be utilized to instruct one or more pieces of equipment (e.g., for data acquisition, valve control, location of a leak in the field, etc.). As shown, the browser application component 820 may be utilized to access one or more features of the system architecture 800 and, for example, alter, adjust, interact, acquire, monitor, etc. performance of one or more of the components (e.g., components and/or frameworks). As an example, an LDS can include one or more features of the system architecture 800 and can be suitable, for example, to execute a method such as, for example, the method 600 of FIG. 6 .

As an example, one or more LDS models can retrieve real-time data from a SCADA/Distributed Control System (DCS)/Process Control System (PCS) via an Object Linking and Embedding (OLE) for Process Control (OPC) Data Access (DA) component (see, e.g., the field data component 810). In such an example, the SCADA/DCS/PCS system can provide information to an OPC server and the LDS can connect to the SCADA/DCS/PCS system using an OPC client. OLE for Process Control (OPC) can include one or more types of data transportation technologies, which can include those other than OLE (e.g., .NET™ framework, XML, binary-encoded TCP format, etc.).

As to leak detection warnings, alarms and/or identified leak locations, one or more of these can be made available for presentation in a SCADA/DCS/PCS system and/or one or more other systems, etc. As an example, one or more automatic shutdown actions may be configured in a field DCS, for example, based at least in part on one or more leak alarms generated by an LDS.

As an example, a real-time framework can receive and transmit data between an LDS and a SCADA/DCS/PCS system. For example, a RT framework may provide data marshalling between various system components (e.g., a data historian, OLGA, or other simulator, one or more visualization frameworks, etc.).

As an example, an LDS can include a data historian component that can provide for storing results generated by the LDS. As an example, a sampling frequency can optionally be configured (e.g., consider a range of approximately 5 second or more (e.g., 15 seconds or more)). As an example, data may be stored for a determined period of time (e.g., a number of years and/or as limited by disk space, etc.). As an example, one or more historical trends may be determined by analysis of data and may be accessible via one or more Graphical User Interfaces (GUIs), for example, as implemented by a browser and/or other application(s).

OASE is a PYTHON® scripting engine and can be, for example, utilized for execution of one or more leak detection and/or location estimation algorithms. Dyno may be utilized as part of a visualization framework (see, e.g., the visualization framework 878), which may be part of a web user interface system. As an example, a server can host various LDS features and, for example, a web server running one or more user interface applications. As an example, a user interface may be accessed via a web browser application (e.g., INTERNET EXPLORER®, FIREFOX®, SAFARI®, etc.), which can allow one or more users to log in remotely (e.g., depending on IT security policies, etc.).

Various figures show various graphical user interfaces (GUIs) where such GUIs may be rendered to a display or a display surface (e.g., via projection, etc.) via execution of instructions by one or more processors. For example, a framework that provides for leak detection can include instructions executable to render one or more of the GUIs, for example, as part of a method, a workflow, etc.

As an example, a SCADA may provide for user input that can instruct an LDS. For example, where a graphic includes a feature or features that may indicate a location of a leak or a possible leak, user input may instruct the LDS to further assess one or more portions of a fluid production network and/or to take one or more other actions (e.g., model revision, etc.).

As an example, where a vehicle (e.g., truck, drone, submarine, etc.) is deployed to a leak location, the location of the vehicle may be tracked and rendered to a graphical user interface (e.g., as a moving graphic en route to a leak location). As an example, where more than one leak occurs, multiple leak graphics and/or locations may be rendered to a display (e.g., as part of one or more GUIs, etc.).

As explained, pipelines and networks of pipelines can be on-shore, off-shore and combined on- and off-shore and fluid can be single- or multi-phase.

As explained, transport pipelines and pipeline networks can experience one or more leaks, which may be of a particular size, sizes, etc. In various instances, an offshore production network can include “weak connectors” that have been installed for deliberate breakage if an external force on the pipeline becomes excessive. For example, consider external force as a consequence of an iceberg dragging along a seabed and contacting a pipeline, a fisherman's net being hooked up on a pipeline, etc. In such scenarios, overall damage may be reduced through pipeline rupture at one or more of a set of fixed controlled positions, which may be possible to close off. In contrast, consider external force that causes an uncontrollable rupture at a wellhead or wellheads.

As an example, connectors, bends, and pipeline welding joints at and around wellheads and manifolds can be exposed to higher risks for leaks than in factory fabricated pipeline segments.

As an example, a leak detection system can operate without a priori knowledge of fixed leak positions and/or fixed leak sizes. For example, consider a leak detection system that relies expressly on prior knowledge of leak positions and/or leak sizes. Such a system may acquire data from a dedicated leak detection sensor positioned on a pipeline where a signal from that sensor indicates a leak has occurred at a portion of the pipeline within the sensing range of that sensor. In such an example, the dedicated leak detection sensor can be programmed, built, or calibrated such that a signal from the dedicated leak detection sensor is directly related to a leak size. In such an approach, the dedicated leak detection sensor can generate a signal that relates, via prior knowledge, to leak location (e.g., via installation location) and leak size (e.g., via programming, building or calibration).

As to a leak detection system that can operate without prior knowledge as associated with dedicated leak detection sensors, consider an example where non-dedicated sensors are utilized. Such non-dedicated sensors can include one or more of temperature sensors, pressure sensors, phase sensors, density sensors, emulsion sensors, etc.

As an example, a leak detection system can provide for detection of leaks where a leak can be an outward leak or an inward leak. For example, where a hole exists that provides for fluid communication between an interior volume and an exterior volume, depending on various conditions, flow may be from the interior volume to the exterior volume or flow may be from the exterior volume to the interior volume. For example, consider a pressure differential between interior and exterior volumes that can, based on sign, cause an outward leak or an inward leak.

As to an inward leak, consider a seabed pipeline in salt water where salt water may flow into the seabed pipeline. In such an example, one or more properties of the salt water can, depending on types of sensor or sensors, help in determining leak location, leak size, etc. For example, consider mixing of salt water and oil where one or more electrical properties, one or more densities, etc., may change due to presence of the salt water.

As an example, a leak detection system that does not rely on fixed leak positions and/or fixed sizes, may be suitable for application to one or more different types of transport pipelines or networked systems, for example, without a demand for pre-application assumptions on leak position and/or size. However, where such information is available, such a leak detection system may be augmented (e.g., supplemented) using such knowledge.

As an example, when a leak (e.g., consider fluid flowing out of the production pipeline or pipeline network) occurs, a production system can be exposed to ambient conditions. Such exposure can affect measurements and the values of measured data points in the production system.

In various instances, a transportation pipeline and/or a network is defined without consideration of a wellhead or wellheads. In such instances, instrumentation (e.g., sensors, etc.) at or associated with a wellhead or wellheads may not be considered. As explained, one approach can be to use dedicated leak detection sensors, which can be without utilization of one or more other types of sensors. In such an approach, the number of measurements available may be limited to those of the dedicated leak detection sensors. In a wellhead inclusion approach, however, signals from one or more of multiple pressure sensors, temperature sensors, etc., may be available. For example, consider a wellhead that is equipped with a flow meter, which may be a multiphase flow meter. In such an example, a leak detection system may utilize one or more signals from such a multiphase flow meter.

As an example, if pre-assumptions on leak positions are applied, these positions can be in the production network at some distance away from wellhead instrumentation. Furthermore, such positions can be isolated from one or more of the wellheads due to valves being in a closed position. Thus, there can be a demand for a way to infer measurements and variables in the production pipelines and network.

As an example, a leak detection system (LDS) can include some amount of redundancy. For example, consider an LDS that provides for receipt and analysis of signals from wellhead sensors, which can be from multiple wellheads. As a reservoir can be in fluid communication with multiple wells via, for example, wellbore perforations, etc., a leak may impact conditions at multiple wellheads. For example, consider two neighboring wells where each of the wells is in fluid communication with a common reservoir. In such an example, flow in the wells can be driven by a first fluid pressure differential for a first one of the wells and a second fluid pressure differential for a second one of the wells. In such an example, there may be some amount of pressure being balanced as the wells, via at least the reservoir, are in fluid communication. For example, consider a situation where a leak occurs in a portion of a pipeline network of the first well, which may cause an increase in the first pressure differential (e.g., lower downstream pressure) such that there is an increase in fluid flow from the reservoir to the first well. In such an example, flow may decrease to the second well, which may be indicated via a flow meter sensor of a wellhead of the second well. As an example, an LDS can understand a leak better through use of signals from multiple sensors, where one or more of those sensors may be remote from a leak and/or in fluid communication with the leak via one or more intermediate structures, which can include, for example, a reservoir (e.g., porous rock filled at least in part with one or more fluids, etc.).

As an example, a simulator or simulation may include reservoir simulation where a reservoir is in fluid communication with one or more conduits (e.g., wells, etc.). For example, consider the ECLIPSE simulator, the INTERSECT simulator, etc., as to reservoir simulation which may be operatively coupled to an OLGA framework, a PIPESIM framework, etc.

As explained, multiple wellheads may be in fluid communication with a common manifold. For example, consider three wells, each with its own wellhead, including pipes that extend from each of the wellheads to a common manifold, which may provide for directing three flow streams into a single flow stream, which may be directed to one or more pieces of processing equipment (e.g., a separator, etc.).

As an example, an LDS can provide for acquiring and analyzing measurements for wellheads connected to a manifold, which can thereby provide some amount of redundancy. As to how large this redundancy is, may also be dependent on a number of transport pipelines connected to the manifold. At the same time, at other manifolds, other wells might be connected to the same production flowline. Thus, an inferred measurement or variable in a production flowline may depend on number of wellhead measurements at different manifolds. To infer measurements some distance away from the actual measurement positions, an LDS can include a model or models (e.g., relational model, physical model, etc.). As an example, an LDS can utilize relationships between different flow lines for purposes of real-time leak detection.

As an example, an LDS can include features for real-time leak detection where leak detection signals evolve over time, which can be due to one or more types of real-world physical phenomena. As mentioned, where flow lines are in fluid communication via a common reservoir, a leak in one flow line may, over time, cause a change in one or more of the other flow lines. Where such one or more other flow lines include one or more sensors, sensor signals may be acquired and analyzed in real time, for example, in a multi-dimensional parameter space. Such an approach can help to locate a leak, determine a leak size and/or determine a type of leak (e.g., outward, or inward, etc.). As an example, an LDS can include a real time model (RTM) that provides for real time leak detection and analysis.

As an example, an RTM approach can consider redundancy in a measurement of a certain type (e.g., pressure, temperature, flow, etc.) in a spatial multivariable system. As an example, an LDS may include utilization of redundancy in measurements and variables one-by-one at a common location where, for example, the LDS can perform transform combinations of reconciled measurements into a single scalar signature. As explained, an LDS can be distributed in a manner with redundancy that is distributed where, for example, the LDS can consider multivariable signatures and utilize redundancy in measurements appearing from different measurement positions in a production pipelines and network of pipelines.

As explained, an LDS can be a model-based LDS in that it utilizes an on-line real time model (RTM). In such an example, the RTM can accurately describe and simulate behavior of a production network by applying operational changes as occurring in the real production system to the real-time model. As an example, such a model can be utilized to characterize responses to one or more different leaks in an off-line or semi on-line manner. As an example, a model may be used on-line to infer measurements at positions where there are no measurements.

As an example, an LDS can utilize multivariable leak signatures. For example, consider an approach that utilizes dynamic signature movement in an n-dimensional space, where n is the number of applied leak signatures, as may be constrained by one or more of physical laws, layout of the system, sensor location, mode of operation, etc. As an example, constraints can be “as accurate as possible” described by an RTM.

As an example, an LDS can characterize several expected normal operation regions in terms of multivariable leak signatures. As an example, a union of expected normal operational regions can define an operational envelope. As an example, a leak detection algorithm can characterize, a priori, various leak regions through simulated data (e.g., executing one or more pipeline and/or reservoir simulators, etc.). As an example, an LDS can characterize, a priori, region(s) of transition(s) from an expected normal operational region or regions, which can be specific to a leak region.

As an example, an LDS can operate such that confidence to a leak is gradually built up as the current operation moves from normal operation towards the transition region, inside the transition region towards the leak regions and finally ends inside a leak region. In such an example, a last identified leak region can provide an indication of expected leak position and size. In such an example, if the operation is intervened by an operator before it enters the leak region, a last transition region can provide a most likely leak position.

As an example, an LDS can be operatively coupled to one or more vehicles such as subsea, land and/or air vehicles. For example, consider an LDS that can instruct a drone to a particular location where coordinates can be changed in real time as confidence as to an expected leak location increase. As an example, a subsea vessel (e.g., underwater drone, etc.) may be following a particular inspection pattern where the pattern may be interrupted by a call by an LDS to direct the subsea vessel to a particular location.

As an example, sometimes for small leaks, a leak region and a normal operation region can overlap such that statistical tests in terms of probability ratio of the probability of a leak divided by the probability of no leak (e.g., operation is inside expected operation region) can be utilized to determine if there is a leak or not (e.g., whether or not to issue a leak signal, notification, control action, etc.). As an example, a most likely leak can be a leak region closest to and covering a current operating point.

As to analyses in multidimensional space, consider one or more types of convex hulls. In geometry, the convex hull or convex envelope or convex closure of a shape can be the smallest convex set that contains it. A convex hull may be defined either as the intersection of the convex sets containing a given subset of a Euclidean space, or as the set of the convex combinations of points in the subset. For a bounded subset of a plane, a convex hull may be visualized as a shape enclosed by a rubber band stretched around the subset.

As an example, convex hulls of open sets can be open, and convex hulls of compact sets can be compact. As an example, an algorithmic problem of finding a convex hull of a finite set of points in a plane or other low-dimensional Euclidean space, and its dual problem of intersecting half-spaces, can be fundamental problems of computational geometry. As an example, a space may be more than two or three dimensions.

As an example, convex hulls may be simple polygons, encapsulate Brownian motion, space curves, and epigraphs of functions. As an example, one or more of orthogonal convex hulls, convex layers, Delaunay triangulation and Voronoi diagrams, convex skulls, etc., may be utilized.

As an example, an LDS can utilize one or more types of convex geometrical shapes. For example, consider one or more of n-dimensional boxes/n-orthotopes, parallelotopes and ellipsoids to describe one or more regions. As an example, one type of region may be of one type of n-dimensional shape and another type of region may be of another type of n-dimensional shape. As an example, choice of geometrical shape can affect test criteria for testing inside or outside a region. As an example, where statistical probability ratio is used, ellipsoids may be utilized for geometric shapes. A compact ellipsoid can be the minimum volume ellipsoid; noting that ellipsoids based on covariance matrices may introduce some conditions as various signatures cannot necessarily be assumed to be independent and normally distributed in an expected region. On the contrary, if they were independent and normally distributed, then the minimum volume ellipsoid will coincide with the ellipsoid described by the mean values of the samples and covariance matrix if the entire region is spanned by the samples.

As an example, an LDS can utilize minimum volume ellipsoids, which may be of suitable dimensionality. Such minimum volume ellipsoids can be of lesser volume than n-orthotopes. An orthotope can be a parallelotope whose edges are mutually perpendicular (e.g., an orthotope is a generalization of a rectangle and a cuboid).

FIG. 9 shows an example of a system 900 as a sub-sea production network. As shown, a production system includes dual flowlines (FL-A and FL-B), three manifolds and 9 wells. The number of flowlines, manifolds and wells can differ from those shown in the example system 900.

In normal production such a system can be often operated with the crossover valves XO-2, XO-3 and XO-4 closed and each well routed to either flowline (FL-A or FL-B). In such normal production operation, the system 900 can be considered as two independent production systems. In FIG. 9 , various valves are shown as being controllable to be open or closed, noting that various levels of open may be available (e.g., to control flow rate, etc.).

As an example, a signature or signatures may be utilized to detect a leak in the system 900. In such an example, the signature or signatures can provide for robust leak detection with reduced incidences of false alarms. As an example, an LDS can provide for detection of leaks that may be greater than a particular size as may be determined by a sensitivity analysis of the LDS where incidences of false alarms can be reduced. Incidences of false alarms can cause an operator to lose confidence in an LDS. As to a small leak, consider a flow rate of a small leak being less than 1 percent of a total flow rate in a single-phase pipeline. For a multiphase pipeline, a small leak may be slightly greater in terms of percent, for example, given uncertainties that can exist in multiphase flow (e.g., multiphase that includes gas and liquid). In various instances, field sensor type, quality, proper operation, etc., can impact an ability to detect low levels of leakage (e.g., less than 10 percent).

As an example, an LDS may provide capabilities for detection of one or more sensor related issues. For example, a signature or signatures may be indicative of a sensor related issue without being indicative of a leak. In such an example, a multidimensional space may be defined with normal operations representing no leakage and normal operations as to one or more sensors. In such an example, a signature or signatures can be compared to one or more regions, envelopes, etc., which may indicate: no leak, sensor OK; leak, sensor OK; no leak, sensor not OK; and leak, sensor not OK. As to the no leak, sensor not OK, real time tracking may be utilized to help determine if measurements from the sensor may be driving one or more signatures toward a leak region, which may result in a false alarm where the region is entered due to a sensor issue and not a leak. Such an approach can help to reduce incidence of false alarms due to one or more sensor related issues (e.g., sensor operational issues, data transmission, etc.).

As an example, a method can include generating one or more regions for one or more sensors where data and/or one or more signatures can be tracked to determine if sensor operation is as expected and within a region or regions.

As an example, a method can include utilizing a hierarchical approach to signatures. For example, a leak may be considered to be detected where more than one signature exceeds a boundary (e.g., consider two signatures, three signatures, etc., as being sufficient). As an example, different types of signatures may be at different levels of a hierarchy where one signature is at a level that demands at least one other signature exceeding a boundary and where another signature is at a level that does not demand another signature exceeding a boundary for triggering an alarm. As an example, signatures may be utilized in combination with logic rules along with boundaries (e.g., region boundaries) for purposes of leak detection, sensor issue detection, etc.

As shown in FIG. 9 , the system 900 can include various sensors, valves, pipelines, etc. As an example, an LDS can provide for detection of one or more issues in the system 900 through use of one or more signatures.

FIG. 10 and FIG. 11 show the two independent production systems 1000 and 1100 as part of the system 900 when in normal production operation.

When there is a potential for flow assurance issues like hydrate, wax or asphaltene formation, one or more special modes of operation of a production system can exist. For instance, to reduce risk of hydrate formation during (e.g., long period) shutdown, operation can involve circulation of dead (e.g., stabilized) oil from topside/shore through the production loop with one or more crossover valves open.

In various examples, there can be normal production scenarios with converging network; however, an LDS or LDS may be applicable to network configurations including more specialized operational scenarios such as, for example, as dead oil and hot water circulation.

FIG. 12 shows an example of a system 1200 that can provide for one or more types of specialized operation scenarios.

As an example, when a production system is operated as a converging network as in FIG. 11 , there can be four measurement positions: topside/model outlet; manifold two; manifold three; and manifold four. And, for example, there can be two independent systems. In various examples, a “half” system can be considered to illustrate operations of an LDS. As an example, where there is reference to signature X_(i), where i∈{1, 2, 3, 4}, that means the signature applied to the measurements at position i. With signature X_(ij), where i∈{1, 2, 3, 4} and j≠i, j∈{1, 2, 3, 4}, consider a signature applied to combination of measurements at positions i and j.

FIG. 13 shows an example of a system 1300. As to inferred measurements, consider a subsea manifold with wells producing to either of two flowlines (FL-A and FL-B) as shown in FIG. 13 . For sake of description, consider a manifold model as in FIG. 14 (see, e.g., a manifold model 1400). In such a model, consider an LDS that aims to infer the flowline pressure (P) from the wellhead pressures. In such an example, the inferred variables are dependent on the valve openings vi and at least one of the valves v_(1j) is to be open. In such an example, let vi be a variable of value 0 if valve ij is closed (does not contribute to the inferred pressure) and value 1 if valve ij is open. Then the row vector:

V _(1j) =[v ₁₁ v ₁₂ v ₁₃]

-   -   includes zeros and ones according to which valves are closed and         open.

Now, let Δ{tilde over (p)}_(1j) represent the pressure drop from measurement p_(1j) to the inferred variable P where column vectors are:

P _(1j) =[p ₁₁ p ₁₂ p ₁₃]^(T)

Δ{tilde over (P)} _(1j) =[Δ{tilde over (p)} ₁₁ Δ{tilde over (p)} ₁₃ Δ{tilde over (p)} ₁₃]^(T)

Then, consider:

$\overset{\_}{P} = {\frac{V_{1j}\left( {P_{1j} + {\Delta{\overset{\sim}{P}}_{1j}}} \right)}{{\sum}_{j}v_{1j}} = \frac{V_{1j}\left( {P_{1j} + {\Delta{\overset{\sim}{P}}_{1j}}} \right)}{{V_{1j}}_{1}}}$

Above, while Δ{tilde over (P)}_(1j) is unknown, an estimate can be given by the RTM:

∥V _(1j)∥₁=Σ_(j=1) ³ |v _(1j)|.

The equation for P considers the p_(1j) where v_(1j) are open. However, if an LDS has a measurement error or bias in one of the p_(1j) and ∥V_(1j)∥≥2 the LDS might consider removing p_(1j) for j such that

$\max\limits_{j}{❘{\overset{\_}{P} - p_{1j}}❘}$

and obtain a new estimate P by excluding p_(1j).

Note, if the RTM includes a model of the manifold, an LDS can reconcile Δp_(2j) towards Δ{tilde over (p)}_(2j) for a given valve opening v_(2j). In such an example, the approach can give an alternative estimated {tilde over (p)}_(1j) that may be worth consideration for inclusion in the equation for P.

In the foregoing example, flowline FL-B has been considered; however, as explained, flowline FL-A can be considered along with FL-B. For example, consider the following equation:

$\begin{bmatrix} {\overset{\_}{P}}^{A} \\ {\overset{\_}{P}}^{B} \end{bmatrix} = \begin{bmatrix} \frac{V_{1j}^{A}\left( {P_{1j}^{A} + {\Delta{\overset{\sim}{P}}_{1j}^{A}}} \right)}{{V_{1j}^{A}}_{1}} \\ \frac{V_{1j}^{B}\left( {P_{1j}^{B} + {\Delta{\overset{\sim}{P}}_{1j}^{B}}} \right)}{{V_{1j}^{B}}_{1}} \end{bmatrix}$

The foregoing approach can operate utilizing an assumption that P ^(A) and P ^(B) are independent of each other; however, if, for example, a cross over valve or both routing valves at a well are open, then P ^(A) and P ^(B) can be related, which may call for further analysis. In such an approach, an LDS can detect one or more operating conditions and one or more appropriate analyses.

As an example, an LDS can perform model-based leak detection using an on-line real time model. As explained, an LDS can be model based where an on-line dynamic model can be run in real-time in parallel with the plant (e.g., production pipelines or network of pipelines subject to potential leaks). In such an approach, the RTM can be utilized to model and simulate behavior of the production network by applying operational changes as occurring in the real production system to the RTM. The model scope and model boundary conditions can be tailored such that the model covers the normal operating envelope and the modes of operation where leak detection is to be applied. In addition, particular values of inlet and outlet boundary conditions can be exposed to reconciled measurements. For example, such model boundaries can be specified in accordance with reconciled measurements. Furthermore, an RTM can be subject to (e.g., batch-wise) tuning so that, for example, pressure and temperature drops in an RTM matches reconciled measurements from the system.

As an example, an LDS can utilize an RTM that is a reference for no leak events (e.g., normal operation without leaks). In such an approach, a leak can then be observed as a deviation from the RTM using one or more criteria (e.g., probability, statistical, etc.). In various instances, a deviation does not necessarily mean that a leak can be immediately observed. For example, for small leaks it can take some time for a deviation or deviations to meet one or more criteria (e.g., region-based criteria, etc.) to be distinguished from, for example, one or more of model errors and measurement noise. As an example, a criterion can be specified in the form of a “footprint” or other type of shape. As explained, a region may be a normal operational region where an excursion or excursions from the normal operational region are indicative of a leak. As explained, in a real time system, data can be streamed where multiple data points are acquired and processed for comparison to one or more regions and/or other region-based analysis. For example, consider transient analysis, which may include utilization of forward projections as to trends, which may be within some zone of uncertainty to help assess whether or not a trend is indicative of a leak transient that is likely to eventually breakout of a normal operational region.

As an example, various types of LD algorithms can be model based in the sense that the responses to potential leaks can be simulated a priori using the model off-line or semi on-line. In this context semi on-line means that the most recent tuned on-line model is used to simulate the response to the leaks and off-line means the model used to simulate responses to the leaks does not have connection to the real time on-line model. A model can be an advanced engineering model, which may be a best possible representation of the real system; noting that the parameters in a model do not demand adjustment such that the model response fit measured data. Thus, off-line can mean before commissioning and tuning of the on-line real time model to measured data.

As explained, an LDS can utilize leak signatures. A leak signature can be a strong indicator of a deviation (e.g., a potential leak) such that a leak signature is a measure for a potential leak. One or more of various types of signatures may be utilized for leak analysis and/or leak detection. As an example, an LDS can utilize multivariable leak signatures that are or include a combination or combinations of multiple leak signatures. As an example, leak signatures of different types can be combined by an LDS.

As to some examples, consider one or more of the following types of leak signatures: (a) measured variables; (b) difference between estimated and measured data; (c) normalized difference between estimated and measured data; (d) distance to ambient/target; (e) derived variables, which can include one or more of (i) difference (pressure ΔP_(j,i)=P_(j)−P_(i)), (ii) gradient (pressure) along pipeline, (iii) ratio (pressure

$\left. {R_{j,i} = \frac{P_{j}}{P_{i}}} \right),$

and (iv) estimator for inventory; and (f) multivariable (e.g., leak signatures dependent on more than one set of measured and corresponding estimated variable).

As an example, a leak signature can be defined using one or more properties. As an example, a leak signature based on measured variables alone does not necessarily demand an on-line RTM to the degree as another leak signature. For example, leak signatures based on derived variables can be combined with difference between estimated measured variables (b) or normalized differences (c).

By combining variables an LDS can amplify different properties in the system. For instance, taking pressure difference along the pipeline can be good for a pipeline system with stable operation with little elevation and single-phase applications. As an example, pressure difference may be well correlated with flow and when a leak occurs between the pressure measurements the changed flow can propagate through the pipeline network and affect the pressure drop. However, in multiphase leak detection where one may expect to operate the production system in the region of slug flow, pressure drop over a segment can be impacted by the slug flow and it can be harder to distinguish a leak from a flow variation due to slug flow.

As an example, an LDS can utilize various signatures that have different properties where the LDS can make one or more selections dependent on the application. As an example, combining variables can introduce more combinations than considering the individual variables independently. For instance, having four pressure measurements then six pressure differences or pressure ratios can be formed and if the measurements are connected, they can be interpreted in a physical sense.

As an example, if two measurements are strongly correlated in normal operation and if the correlation changes due to the influence of a leak, then taking the ratio can introduce a strong signature since the leak can break the correlation (e.g., according to one or more criteria as to correlation, correlations, etc.). In such an example, consideration of pressure ratios can improve signal to noise ratio.

As explained above, a signature can be a distance-based signature such as distance to ambient and/or target (see, e.g., (d), above). In such an example, a signature can be dependent on an ambient/target condition. This is in a way peculiar, as in an LDS, a leak can now be cast as, or otherwise represent, a new additional boundary condition in the modelling sense. In such an example, the new additional boundary condition can affect principal directions of the system. For example, if the leak is big then a dynamic transition considering the added boundary condition can be rapid with respect to time and can first be visible in an individual signatures close to the leak position (leak location) and over time propagate to the signatures further away. Whereas, if the leak is small, the transients will be smaller and the path in the n-dimensional space (where n is the number of signatures applied) taken by a small leak will be different than for a large leak. As an example, an LDS can consider that a small leak is bounded by the physical system in a different way than a large leak. In such an approach, a large leak can represent a larger disturbance to normal operation than a small leak.

In various instances, dynamics of a system can depend on various types of physical phenomena. For example, consider elevation where gravity can act upon fluid, whether ambient or pipeline fluid. Gravity may make a portion or portions of a system directional with respect to one or more phenomena. For example, consider gravity related pressure head or elevation head, as may be due to fluid weight (e.g., the gravitational force acting on a column of fluid, etc.). As an example, a pressure head can be due to static pressure, the internal molecular motion of a fluid that exerts a force on its container. As to ambient, the deeper a pipeline is below an air/water surface, the greater the fluid head can be, which may impact leak dynamics (e.g., pressure differential for an inward leak or an outward leak). Additionally, if fluid is compressible, gravity can impact such a fluid, which may be germane for multiphase flow. As an example, dynamics of a system can be directional in a manner as to one or more types of phenomena (e.g., pressure, temperature gradients, etc.), which may result in a directionality or directionalities as to how a leak may dynamically affect readings at one or more sensors (e.g., wellhead and/or other sensors, etc.).

As to a leak signature for distance to ambient/target, consider a leak signature X_(i) for position i depending on measurement or inferred measurement M_(i), on-line model estimates E_(i) corresponding to measurement M_(i) and ambient/target value A_(i) is given by:

$X_{i} = \frac{E_{i} - M_{i}}{E_{i} - A_{i}}$

Above, X_(i)≈0 when there is no leak and X_(i)=0 when there is no leak and a perfect model exists. Furthermore, as X_(i) approaches 1, there can be a strong indication that there is a rather large leak near measurement position i (see also, e.g., FIG. 32 ).

As to a revised version of the distance to ambient/target:

${\overset{\sim}{X}}_{i} = \frac{E_{i} - M_{i}}{{❘{E_{i} - A_{i}}❘} + {❘{M_{i} - A_{i}}❘}}$

Note, {tilde over (X)}_(i)∈[−1, 1], that is {tilde over (X)}_(i) is in the range −1 to 1. Thus, {tilde over (X)}_(i)≈0 when there is no leak and X_(i)=0 when there is no leak and a perfect model exists (see also, e.g., FIG. 33 ). As {tilde over (X)}_(i) approaches 1, there can be a strong indication that there is a leak of process fluid from the pipeline to the surroundings near measurement position i. To realize this, consider setting M_(i)=A_(i) to get:

${{\overset{\sim}{X}}_{i} = {\frac{E_{i} - A_{i}}{{❘{E_{i} - A_{i}}❘} + {❘{A_{i} - A_{i}}❘}} = {\frac{E_{i} - A_{i}}{❘{E_{i} - A_{i}}❘} = {+ 1}}}},{{{since}E_{i}} > A_{i}}$

Above, as {tilde over (X)}_(i) approaches −1, there is a strong indication that there is a leak of fluid from the surroundings (e.g., saltwater in an offshore subsea system) of the pipeline near measurement position i. To realize this, again set M_(i)=A_(i) to get:

${{\overset{\sim}{X}}_{i} = {\frac{E_{i} - A_{i}}{{❘{E_{i} - A_{i}}❘} + {❘{A_{i} - A_{i}}❘}} = {\frac{E_{i} - A_{i}}{❘{E_{i} - A_{i}}❘} = {{{- 1}\frac{❘{E_{i} - A_{i}}❘}{❘{E_{i} - A_{i}}❘}} = {- 1}}}}},{{{since}E_{i}} < A_{i}}$

From the foregoing example, it follows that this revised distance to ambient signature has the possibility to distinguish between leaks of process fluid from the pipelines to the surroundings and leaks of surrounding fluid into the pipeline.

As an example, an LDS can operate in terms of pressure in considering X_(i) and {tilde over (X)}_(i), where E_(i) is the estimated pressure and M_(i) is measured pressure at position i. However, an LDS may operate in terms of one or more other measures, etc. (e.g., additionally or alternatively).

As an example, consider a pipeline where flow rate is measured both at inlet and outlet. Also assume that the scope of the real time model includes reservoir condition(s). In such an example, measured flowrate at the inlet of the pipeline is not applied to the real time model as an inlet model boundary condition. Now assume that a moderate to large leak emerges of y % between the two flow measurements and that the leak is to the surroundings. In such an example, consider using the signatures X_(i) and {tilde over (X)}₁ to the flow measurement at the outlet. In such an approach, set A_(i)=0, because a fully developed leak to the surroundings in a pipeline will give zero flowrate at the outlet. Such an approach can get

$M_{i} = {\left( {1 - \frac{y}{100}} \right)E_{i}:}$

${X_{i} = {\frac{E_{i} - M_{i}}{E_{i}} = {\frac{E_{i} - {\left( {1 - \frac{y}{100}} \right)*E_{i}}}{E_{i}} = {\frac{y}{100} = {y\%}}}}}{and}{{\overset{\sim}{X}}_{i} = {\frac{E_{i} - M_{i}}{{❘E_{i}❘} + {❘{\left( {1 - \frac{y}{100}} \right)*E_{i}}❘}} = {\frac{E_{i} - {\left( {1 - \frac{y}{100}} \right)E_{i}}}{E_{i}\left( {2 - \frac{y}{100}} \right)} = \frac{\frac{y}{100}}{2 - \frac{y}{100}}}}}$

In the foregoing example, if y is small then

${{{2 - \frac{y}{100}} \approx {2{and}{\overset{\sim}{X}}_{i}} \approx {\frac{1}{2}\frac{y}{100}}} = {\frac{1}{2}y\%}};$

whereas, if the leak is large then

${{2 - \frac{y}{100}} \approx {1{and}{\overset{\sim}{X}}_{i}} \approx {\frac{1}{1}\frac{y}{100}}} = {y{\%.}}$

Now, for example, consider the inlet. At the point of the leak the pipeline pressure will decrease towards the ambient pressure. The inlet flowrate will increase due to decreasing wellhead pressure. In such an example, set A_(i)=0 and assume that wellhead flowrate increases with z %, then

$M_{i} = {\left( {1 + \frac{z}{100}} \right)E_{i}:}$

${X_{i} = {\frac{E_{i} - M_{i}}{E_{i}} = {\frac{E_{i} - {\left( {1 + \frac{z}{100}} \right)E_{i}}}{E_{i}} = {{- \frac{z}{100}} = {{- z}\%}}}}}{and}{{\overset{\sim}{X}}_{i} = {\frac{E_{i} - M_{i}}{{❘E_{i}❘} + {❘M_{i}❘}} = {\frac{E_{i} - {\left( {1 + \frac{z}{100}} \right)E_{i}}}{E_{i}\left( {1 + 1 + \frac{z}{100}} \right)} = \frac{- \frac{z}{100}}{2 + \frac{z}{100}}}}}$

In such an example, if z is small then

${{{2 + \frac{z}{100}} \approx {2{and}{\overset{\sim}{X}}_{i}} \approx {\frac{1}{2}\frac{z}{100}}} = {{- \frac{1}{2}}z\%}};$

whereas, if the leak is large then

${{2 + \frac{z}{100}} \approx {3{and}{\overset{\sim}{X}}_{j}} \approx {\frac{1}{3}\frac{z}{100}}} = {{- \frac{1}{3}}z{\%.}}$

As an example, an LDS may alternatively consider (see also, e.g., FIG. 34 ):

${\hat{X}}_{i} = \frac{E_{i} - M_{i}}{\sqrt{\left( {E_{i} - A_{i}} \right)^{2} + \left( {M_{i} - A_{i}} \right)^{2}}}$

As to multiple measurements and multivariable signatures, consider multiple measurements making the signature become a vector X in an n-dimensional space. In such an example, a footprint of the transitions in this n-dimensional space can be utilized as they can be different for the different leak sizes and positions.

As an example, an LDS can make use of multiple leak signatures to characterize a multivariable (n-dimensions) pattern that can be used as a footprint for leaks rather than single scalar signature. As explained, logic (e.g., logic rules, etc.) may be utilized for multiple signatures (e.g., as to leak detection, sensor issue detection, etc.).

As to regions, as mentioned, one or more types of regions may be defined, which can include normal, transient, leak, etc. As an example, a region may be dynamic and may change according to a schedule. For example, consider operational conditions that change according to a normal operational schedule. In such an example, a normal operational region may be dynamic with respect to time and, as mentioned, a transient leak can provide for a region, which may be dynamic with respect to time. Thus, in various instances, dynamic regions with different underlying drivers (e.g., operation, leak, normal, abnormal, etc.) may be utilized.

As an example, an LDS may include one or more of the following regions, which may be or include envelopes in a multidimensional space: (1) expected operational regions/envelope; (2) leak regions/envelope; and (3) transient to leak regions/envelope. In such an example, multiple regions may exist in each of the three categories.

As to classifying a region, consider utilization of geometrical shapes (e.g., rectangular right-angled box, ellipsoid, etc.) that can be used to describe a region. As mentioned, a shape may be a geometrical shape that is convex. As an example, principal directions of a geometrical shape can be aligned with axes of signatures. Such an approach can make it somewhat easier to compute the regions (e.g., consider right-angled bounding boxes); however, a resulting region may not necessarily be the most compact (minimum volume) region. In other words, it may include substantial void space. As an example, if the principal axes of a geometrical shape can be dis-aligned with the signature's axes (e.g., where rotation is allowed) then an LDS can provide the most compact (minimum volume) representation of the region for the given geometrical shape.

As an example, an LDS may operate to find a region (for a given geometrical shape) that contains the samples (points) and minimizes the volume that is best suited (e.g., unique, and compact). As an example, principal directions of the geometrical shapes may then not be aligned with the axes of the signatures. Thus, an LDS can operate to find the orientation of the region.

As an example, for ellipsoids there exists a unique minimum volume ellipsoid that contains m-points in the n-dimensional space

^(n) (e.g., assume that the m-points span the n-dimensional space). Various types of efficient numerical algorithms exist to compute such an ellipsoid.

As mentioned, it may be relatively straightforward to compute the right-angled box aligned with the axes of the signatures; however, in the n-dimensional space

^(n), where n>3 it can be harder to compute the minimum volume right-angled bounding box of m-points in

^(n) with an orientation different than the signature axes.

FIG. 15 shows an example of a graphical user interface (GUI) 1500. Specifically, the GUI 1500 shows measured data points M₁, M₂ and the corresponding estimated values E₁, E₂ as a function of time (e.g., measured, and estimated data as sample point versus time). Such a GUI may be rendered in color or one or more other manners to distinguish various points.

In such an example, by applying the relation for a specific signature, the data points can be transformed from (M₂, M₂, E₂, E₄) to (X₂, X₄).

FIG. 16 shows an example of a GUI 1900 that shows the transformed result. Specifically, FIG. 16 shows distance to ambient leak signature

${X_{i} = \frac{E_{i} - M_{i}}{E_{i} - A_{i}}},$

for i=2 and 4 plotted versus time. Such a GUI may be rendered in color or one or more other manners to distinguish various points.

FIG. 17 shows an example of a GUI 1700 that shows the result from plotting X₄ versus X₂, which results in a graphical representation of how the data form a region. Specifically, FIG. 17 shows distance to ambient leak signature

${X_{i} = \frac{E_{i} - M_{i}}{E_{i} - A_{i}}},$

for i=2 and 4 plotted against each other.

FIG. 18 and FIG. 19 show examples of GUIs 1800 and 1900, which corresponds to characterization of a region in terms of alternative geometrical shapes.

In FIG. 18 , the GUI 1800 shows two different rectangles and three different ellipsoids that can describe the data points. Thus, the GUI 1800 shows signature X₄ versus X₂ and the GUI 1900 shows X₂ versus X₁. The GUI 1900 of FIG. 19 is included to illustrate that ellipse E1 is really an ellipse and not a circle and that the boxes are rectangles and not squares.

Specifically, FIG. 18 shows classifying leak signature data in terms of a region, where E1: ellipsoid characterized by mean values and standard deviation of signature vector X; E2: ellipsoid characterized by mean values and covariance of signature vector X; E3: minimum volume ellipsoid characterized by matrix positive semidefinite matrix A and center point c; box characterized by individual minimum and maximum values of X; and box characterized by mean values and standard deviation of X as center and a radius.

Specifically, FIG. 19 shows classifying leak signature data in terms of a region, where E1: ellipsoid characterized by mean values and standard deviation of signature vector X; E2: ellipsoid characterized by mean values and covariance of signature vector X; E3: minimum volume ellipsoid characterized by matrix positive semidefinite matrix A and center point c; and box characterized by individual minimum and maximum values of X.

In the examples of FIG. 18 and FIG. 19 , the inner dotted rectangle is characterized by minimum and maximum values of the variables X_(i), i.e.,

${\check{X}}_{i} = {{\min\limits_{j}X_{ji}{and}{\overset{\hat{}}{X}}_{i}} = {\max\limits_{j}{X_{ji}.}}}$

This is a rectangle aligned with the original axes X₂ and X₄. Note, in this case the smaller rectangle can be found by also considering a rotation (noting that this rotated rectangle is not shown).

As to the outer rectangle, it is characterized by standard deviation for the variable X_(i) and number of standard deviation required to cover the range from X̆_(i) to {circumflex over (X)}_(i), i.e.

${n_{\sigma_{i}} = {{\max\left( {{{\hat{X}}_{i} - {\overset{\_}{X}}_{i}},{{\overset{\_}{X}}_{i} - {\overset{\bigvee}{X}}_{i}}} \right)}/\sigma_{i}{where}}}{\mu_{i} = {{{mean}\left( X_{i} \right)} = {\frac{1}{n}{\sum}_{j = 1}^{n}{X_{ji}.}}}}$

As to the ellipsoid labelled E1, it is characterized by vector mean μ_(X)=[μ₁ . . . μ_(i) . . . μ_(n)], vector of standard deviations σ_(X)=[σ₁ . . . σ_(i) . . . σ_(n)] and the scalar n (not the dimension of the signature vector X). The scalar n is such that one point lies on the boundary of the ellipsoid and the other points lie inside the ellipsoid. In other words, the scaler n is given by the point furthest away from mean μ_(X).

As to the second ellipsoid labeled E2, it is characterized by vector mean μ_(X)=[μ₁ . . . μ_(i) . . . μ_(n)], covariance matrix Σ=Σ_(X) and same scaler n given above. The multivariable probability density function for n-normal distributed variables is also described by mean μ_(X) and covariance matrix Σ. Contour plots of the normal distribution is ellipsoid characterized by μ_(X) and Σ_(X). The shape of the ellipsoid is given the covariance matrix Σ_(X). In such an example, the variables X_(i) cannot be assumed to be independent and normal distributed, which can be readily seen as the entire ellipsoid is not spanned out by the points. There are regions in E2 that do not contain points (e.g., void or voids).

As to the third ellipsoid E3, it is named the minimum volume ellipsoid and it is characterized by the geometrical center c and a positive semidefinite matrix A. Note that the center c=c_(X)=[c₁ . . . c_(i) . . . c_(n)] is not equal to the mean values of the variable. The minimum volume ellipsoid can be found by solving the following minimization problem:

${\min\limits_{c,A}\log{❘A❘}{s.t.\left( {x - c} \right)^{T}}{A\left( {x - c} \right)}} \leq 1$

Note, in the foregoing example, that the center vector c and the positive definite matrix A are free variables in the minimization. The determinant of the matrix det(A)=|A|=Π_(i=1) ^(n)λ_(i), where λ_(i) is the ith eigenvalue of the matrix A. Note that λ_(i)≥0, since A≥0 (positive semidefinite). The constraint (x−c)^(T)A(x−c)≤1 makes sure that points are positioned inside or at the border of the ellipsoid. In domain

² the area covered by the ellipse is minimized. In domain

or

¹ is the distance from the geometrical center that is minimized, the scalar matrix is the inverse of the radius from the center and c is in the middle of minimum value and maximum value of the variable. In domain

^(n) where n≥3, it generalizes to the minimum volume of the n-dimensional ellipsoid.

As to some examples of techniques for minimum volume ellipsoids, consider one or more of the following: Leonid G. Khachiyan, (1996) Rounding of Polytopes in the Real Number Model of Computation. Mathematics of Operations Research 21(2):307-320. https://doi.org/10.1287/moor.21.2.307; Todd, Michael J. (2016) Minimum-Volume Ellipsoids: Theory and Algorithms. MOS-SIAM Series on Optimization. https://my.siam.org/Store/Product/viewproduct/?ProductId=27790110; and Nima Moshtagh (2020) Minimum Volume Enclosing Ellipsoid. MATLAB Central File Exchange, ttps://www.mathworks.com/matlabcentral/fileexchange/9542-minimum-volume-enclosing-ellipsoid, which are incorporated by reference herein.

As an example, a technique as in Geismann et al., The Convex Hull of Ellipsoids, Proceedings of the Annual Symposium on Computational Geometry, 10.1145/378583.378717, SCG'01, Jun. 3-5, 2001, Medford, Massachusetts, USA, ACM 1-58113-357-X/01/0006, may be utilized; noting that Geismann et al. is incorporated by reference herein. The foregoing article describes computation of the convex hull of a set of ellipsoids using an algorithm.

As an example, an LDS may utilize one or more techniques, which may be for an appropriate corresponding shape or shapes. As explained, an LDS may utilize the minimum volume ellipsoids to give compact descriptions of regions; noting that one or more other shapes may be utilized additionally or alternatively (e.g., consider minimum volume right-angled boxes, etc.). As to boxes, algorithms to compute minimum volume right-angled boxes can be complex or unavailable for n>3.

As to expected operational regions and production envelope, as mentioned, an LDS can utilize one or more expected operational regions, which may be steady state, dynamic, etc. As an example, a union of expected operational regions can cover a production envelop.

FIG. 20 shows an example of a GUI 2000 of mapping of signature data into a region. As seen, data may be distributed or characterized using one or more statistical techniques and/or probability techniques as to a distribution or distributions.

FIG. 21 shows an example of a GUI 2100 showing four operational regions E.O.R(1:4) for signature combination X₂, X₃ as well as the union of all expected operational regions. Specifically, FIG. 21 shows expected operational regions E.O.R(1:4) for signature combination X₂, X₃, union of expected operational regions, safety margin (black dashed). E.O.R(3) is quite similar to the union. E.O.R(2) c E.O.R(1,4) c E.O.R(3) s Union.

FIG. 22 shows an example of a GUI 2200 with expected operational regions. Expected operational regions E.O.R(1:4) for signature combination X₁, X₄, union of expected operational regions, safety margin (black dashed) where 1. E.O.R(1) is basis flow and outlet pressure; 2. E.O.R(2) is high outlet pressure, two times the outlet pressure in E.O.R(1), this E.O.R(2) is inside E.O.R(1); 3. E.O.R(3) is low outlet pressure, this region is coinciding with union region so it is not visible in the GUI 2200. E.O.R(3) covers both E.O.R(1), E.O.R(2) as well as E.O.R(4); 4. E.O.R(4) is increased flowrates; 5. E.O.R(1) has some smaller region outside the union. But in that region of E.O.R(1) there are no points. The union is created by assembling the points for the four E.O.R(1-4) and then creating a minimum volume ellipsoid of union of the points. An alternative way would be creating the union of the four E.O.R regions. This would create a slightly bigger union. Based on the union and scalar safety factor it is possible to assemble the safe region. As an example, the safety factor can be less than 1. In the GUI 2500, where a 20% safety factor is applied, then the safety factor can be 1.2.

As an example, an LDS can be dynamic where the production envelope and expected operational regions can be updated on-line with new reconciled on-line measurements. As an example, expected operational regions can be complemented with offline and/or semi-offline simulations. As mentioned, an operational schedule may be utilized for dynamic generation of one or more regions.

As explained, an LDS may operate using various types of information, sensor data, etc. For example, based on valve positions and mode of operation (normal production, fluid circulation, shutdown etc.), an LDS can determine an appropriate expected operational region.

As an example, an LDS can utilize one or more leak regions and, for example, a leak envelope. As an example, a leak region may be mimicked but not necessarily replicated in a system as damaging the system to generate a leak can be unacceptable. As to mimicking a leak, where a valve is available that can be coupled to a vessel, a pipeline, etc., to accept fluid, that valve may be utilized, however, it is a fixed valve at a fixed location. Thus, in general, at best it may be possible to update via reconciled on-line measurements for a fixed location mimicked leak; and not an actual leak as to characterizing a leak region. However, by using a rigorous multi- (or single-, depending on the application) phase simulator, an LDS can classify a leak region for a specific position and size. For example, by varying the leak size and taking the union of data for different sizes, an LDS can classify a leak region for a given position. In such an example, the union of data for leak positions (and sizes) can be generated to represent an expected leak region or envelope for a given system. As an example, leak regions of different discrete sizes at a given position can relate to each other in the sense that larger leak sizes can appear further away from the expected normal operation region than smaller leaks. For example, for small leaks, the leak region and the normal expected operational region can/will overlap as the leak size approaches zero (e.g., a limit-based approach). As an example, the area (when number of signatures is two) or volume (when the number of signatures >2) of a leak region will also vary. As an example, smaller leaks (1% to 10% of area) will in most cases have larger sizes (areas/volumes in multidimensional space) than large leaks like 60%, 80% or 100% of pipe area.

FIG. 23 shows an example of a GUI 2300 that shows leak regions for eight possible leaks sizes as well as the leak union region. The leak position is close to position 4. The leak sizes vary from 3% to 100% of pipe area. Specifically, the GUI 2300 shows leak regions LR(1:8) for signature combination X₁, X₄, union of all leak regions: LR1, leak with size 3% of flowing area; LR2, leak with size 5% of flowing area; LR3, leak with size 11% of flowing area; LR4, leak with size 20% of flowing area; LR5, leak with size 40% of flowing area; LR6, leak with size 60% of flowing area; LR7, leak with size 80% of flowing area; LR8, leak with size 100% of flowing area; and leak union region; noting that LR(1) and LR(2) outside leak union region contain no sample points.

As an example, an LDS can utilize leak transient regions bridging the expected operational region to the leak region. For example, when simulating the leaks of different size for a given position, an LDS can see how operation goes out of the normal expected operational region and approaches the leak region. Due to constraints imposed, the movement from the expected operational region to leak region can go in one or more of certain directions. These directions can be collected in terms of the simulated data and characterized in regions for the transient from expected normal operation to the leak region. As an example, the leak transient regions can overlap with both the expected operational region and the leak region for the given position. In such an example, a GUI can render a graphic that represents a bridge between the expected operational region to the leak region.

FIG. 24 shows an example of a GUI 2400 with graphical representations of transition regions from expected operation to eight possible leak regions as well as the union of the transition regions. In such an example, the leak position is close to position 4 where the leak sizes vary from 3% to 100% of pipe area.

Specifically, in FIG. 24 , the leak transition regions TR(1:8) for signature combination X₁, X₄, union of the transition regions where TR1, transition from E.O to leak region LR1 with leak size 3% of flowing area; TR2, transition from E.O to leak region LR2 with leak size 5% of flowing area; TR3, transition from E.O to leak region LR3 with leak size 11% of flowing area; TR4, transition from E.O to leak region LR4 with leak size 20% of flowing area; TR5, transition from E.O to leak region LR5 with leak size 40% of flowing area; TR6, transition from E.O to leak region LR6 with leak size 60% of flowing area; TR7, transition from E.O to leak region LR7 with leak size 80% of flowing area; and TR8, transition from E.O to leak region LR8 with leak size 100% of flowing area; noting that transition union region where TR7 and LR8 outside transition union region contains no sample points. In the example of FIG. 27 , dotted black lines are the trajectory for the transition from the expected operation region to the leak region.

FIG. 25 shows an example of a GUI 2500 where expected operation region, leak regions, leak union region and transition union region for signature combination X₁, X₄ are shown. FIG. 25 illustrates combinations of expected operation, leak transition region and leak regions. In particular, FIG. 25 shows expected normal operation region, leak regions, the leak transition region as well as trajectories from the E.O.R to the different leak regions; note the differences in the paths.

As an example, an LDS can assess the transition from expected operational region to the leak region. For example, prior to a leak, the system will be inside the expected normal operation region. Thus, the operation during a leak will start in the normal operation region, move into the overlap between the transient region and the normal expected region, go out of the normal expected region but still being inside the transient region. It can move in a transient region with a major component (principal axis) towards the leak region. It can then enter the leak region. On its way it can pass through one or more other leak regions (different size and/or position).

FIG. 26 shows an example of a GUI 2600 where an expected operation region, leak regions, leak union region and transition union region for combinations of two signatures X_(i), X_(j) with leak close to position 2 are shown.

FIG. 27 shows an example of a GUI 2700 where an expected operation region, leak regions, leak union region and transition union region for all combinations of two signatures X_(i), X_(j) with leak close to position 3.

FIG. 28 shows an example of a GUI 2800 where an expected operation region, leak regions, leak union region and transition union region for all combinations of two signatures X_(i), X_(j) with leak close to position 4.

The plots in the GUIs 2600, 2700, and 2800 correspond to the possible combinations of two signatures and three different leak positions.

As an example, an LDS can include testing for memberships in one or more different regions to provide an indication if a leak is present or in development and, for example, the most likely leak position and/or size. As mentioned, logic (e.g., logic rules, etc.) may be utilized for leak detection, sensor issue detection, etc.

As an example, multivariable patterns described when a leak occurs can be sufficiently clear and differ depending on the leak position and size. As explained, small leaks tend to move in the directions of the principle axes of the leak regions. These directions can be dominated by the model and the closure of the model boundaries. As to the latter, consider the expected operational regions where one of the signatures is X₁. In such plots, the ellipsoid of the expected operational region has the smaller radius in the direction of X₁. This means that, in normal operation there is less room for variations in the direction of X₁. This is due to the model boundary applied to the real time model at the outlet of the system; noting that leak regions can still be oriented in the main direction imposed by a model. The outlet model boundary condition can still apply; however, a bit upstream of the outlet boundary there may be a check valve. When a leak of a certain size appears due to one or more controller actions, this check valve can be instructed to close via an actuator, thereby causing a deviation in measurement position 1. For example, consider details of the plots with signature X₁ where the main axis of the leak regions of larger sizes are more oriented in the direction of X₁ than the main axis of the leak region describing the smallest size. This is due to the impact of the check valve closing and prohibiting the outlet boundary to propagate upstream of the check valve for the larger leaks.

As an example, for a signature combination of X₃ and X₄, model relations can impose that there is almost a one-to-one relation (e.g., ellipsoids are long and narrow oriented in almost 45 degrees) between X₃ and X₄ in normal operation as well as when leaks appear (e.g., independent of size and position of the leak).

As to various test criteria, an LDS may, for example, assume a vector of signatures x∈

^(n) with center or mean (depending on context) x∈

^(n), radius r∈

^(n) Let A be a positive definite matrix A∈

^(n×n) such that vAv>0 for all v∈

^(n). Let X∈

^(m×n) be a matrix of m row vectors of signatures x_(i)∈

^(n) and x_(ji)∈

,

$X = \begin{bmatrix} X_{1} \\  \vdots \\ X_{j} \\  \vdots \\ X_{m} \end{bmatrix}$

In such an example, a LDS can compute the vector of mean x as

${{\overset{\_}{x}}_{i} = {\frac{1}{m}{\sum}_{j = 1}^{m}x_{ji}}},$

standard deviation

${\sigma_{i} = \sqrt{\frac{1}{m}{\sum}_{j = 1}^{m}\left( {x_{ji} - {\overset{\_}{x}}_{i}} \right)^{2}}},{{{maximum}{\hat{x}}_{i}} = {\max\limits_{j}x_{ji}}},{{{minimum}{\overset{\bigvee}{x}}_{i}} = {\min\limits_{j}x_{ji}}},{n_{\sigma i} = {{{\max\left( {\frac{{\hat{x}}_{i} - {\overset{\_}{x}}_{i}}{\sigma_{i}},\frac{{\overset{\_}{x}}_{i - {\overset{\bigvee}{x}}_{i}}}{\sigma_{i}}} \right)}{and}r_{i}} = {n_{\sigma i}{\sigma_{i}.}}}}$

In such an example, the radius is given relative to the signature axes.

As explained, the center of minimum volume ellipsoid can be a geometrical center where it is not equal to the mean x. And, for example, the radius r_(i) can be given by the matrix A (e.g., not the equations above). As an example, if an ellipsoid is described by mean x and covariance of X, Σ_(X) then the shape and radius of the rotated ellipsoid is given by a covariance matrix.

As an example, an LDS may operate using one or more of the following multivariable test criteria: 1—region based test criteria based on ellipsoids; 2—region based test criteria based on boxes (“sum of individual criteria”); and 3—region based test criteria based on parallelohedron.

As an example, consider vector-based ellipsoid described by center x and radius r with the following:

Outside Region

$\sqrt{\sum\limits_{i = 1}^{n}\frac{\left( {x_{i} - {\overset{\_}{x}}_{i}} \right)^{2}}{r_{i}^{2}}} > 1$

Inside Region

$\sqrt{\sum\limits_{i = 1}^{n}\frac{\left( {x_{i} - {\overset{¯}{x}}_{i}} \right)^{2}}{r_{i}^{2}}} \leq 1$

As an example, consider vector-based ellipsoid described center x and positive (semi-)definite matrix A with the following:

Outside Region

√{square root over ((x−x )^(T) A(x−x ))}>1

Inside Region

√{square root over ((x−x )^(T) A(x−x ))}≤1

As an example, consider region-based test criteria based on boxes (“sum of individual criteria”) mean x with the following:

Outside Region

${\sum\limits_{i = 1}^{n}\left\{ {{❘{x - {\overset{¯}{x}}_{i}}❘} > r_{i}} \right\}} \geq k$

Strictly outside

^(k), partly outside

^(n)

Inside Region

${\sum\limits_{i = 1}^{n}\left\{ {{❘{x_{i} - {\overset{¯}{x}}_{i}}❘} \leq r_{i}} \right\}} \geq k$

Strictly inside

^(k), partly inside

^(n)

As an example, consider region-based test criteria based on parallelohedron (“linear with mean x”) with the following:

Outside Region

${\frac{1}{\sqrt{n}}{\sum\limits_{i = 1}^{n}\frac{❘{x_{i} - {\overset{¯}{x}}_{i}}❘}{r_{i}}}} > 1$

Inside Region

${\frac{1}{\sqrt{n}}{\sum\limits_{i = 1}^{n}\frac{❘{x_{i} - {\overset{¯}{x}}_{i}}❘}{r_{i}}}} \leq 1$

As an example, an LDS can operate using a leak detection algorithm based on expected normal operation region, transient regions, and leak regions. As explained, an LDS can characterize a leak situation in terms of movement in and between the following three regions: expected operational regions/envelope; leak regions/envelope; and transient to leak regions/envelope.

As an example, an LDS can perform testing if a current operation point is inside or outside these regions, which can give rise to eight (23) cases. In such an example, at least six out of these cases might happen, as set forth in Table 1 below.

TABLE 1 Potential cases based on classification inside or outside the regions/envelopes. # LR TR E.O Description 1 0 0 0 Outside all regions, operation is in a region not covered 2 0 0 1 Normal operation 3 0 1 0 In transient towards a leak outside E.O, warn for potential leak 4 0 1 1 Inside E.O and inside TR, early warning of potential developing leak situation 5 1 0 0 Leak 6 1 0 1 Leak (and E.O), might be due to a wrong construction of TR's 7 1 1 0 Leak 8 1 1 1 Leak (see below)

As to case #8, assume that a small leak appears. The leak size is so small that leak region for that leak position and size overlap the expected operational envelope. Then there exists at least one possible path so that transient path “from E.O to the specific LR” is completely inside E.O. In this case operational point can exist in all three regions at the same time.

As to case #1, the three region/envelopes might not cover the complete

^(n). For case #1 and case #6 in the table above, if those occur an LDS may consider updating some of the regions.

As an example, leak detection in some cases can be determined using one or more of: (1) everything outside normal operation (with a safety factor) is a leak; (2) outside normal operation (with a safety factor) and inside TR or inside LR is a leak; and (3) demand that a process goes form normal operation (E.O) into TR and then into LR as sequence from case #2 to case #4 to case #3 to case #7 which ends in case #5, raising warnings and alarms at different levels.

Note that in FIG. 24 , the transition regions for the larger leaks TR5 to TR8, (corresponding to leak sizes 40% to 100% of pipe area), becomes rather large. Instead of making one region, an LDS may consider dividing the trajectory into two (or more) and construct two regions (or more), A and B, with some overlapping points. In such an example, one region TR(5:8, A) going from E.O with main axis in the direction of X₄ and a second region TR(5:8, B) going from TR(5:8; A) to LR(5:8). In such an example, the transient region for large leaks can become more compact. Such an approach can increase level of detail in Table 1.

As an example, a bounded right-angled box aligned with the signature axes will describe such (A and B) regions well because the trajectories for large leaks will be aligned with the axes of the signatures close to the leak positions (due to the physics).

As an example, an LDS can utilize one or more components that can provide for tailored operation with respect to a system (e.g., a plant) or a portion thereof. For example, consider an approach that aims to balance the complexity with detection specifications, along with, for example, usefulness and potential failures of the algorithms/logic. As an example, instead of making one fixed leak detection algorithm, an LDS may provide for tailoring one or more leak detection algorithms to the specific project requirements, desires, etc.

As an example, a signature vector X can be a vector in

^(n). In such an example, an LDS can consider combinations of two signatures or more to uncover behaviors, for example, using graphics, graphical techniques, geometry, probability, statistics, etc. As an example, an LDS may use as many signatures as possible to take advantage of redundancy. However, when designing a leak detection algorithm, an LDS can consider if each of the signatures are likely to be applied or not. As an example, if one or more measurements are too un-reliable, causing a signature to trigger a false alarm, then an LDS might exclude that signature (e.g., if the remaining number of signatures is sufficient). In other words, sensitivity to measurement failure and error can be a reason to reduce the number of signatures used from maximum (e.g., by one or two, etc.).

As explained, an LDS can utilize a region-based approach that utilizes an RTM where multivariable signatures can exist within multidimensional regions.

As an example, an LDS can utilize multivariable signatures X∈

^(n) of possible different types and convex geometrical shapes to describe regions of expected operation, regions of transition to leak and regions of leak. As an example, an LDS can utilize a signature distance to ambient/target that considers the ambient condition at the measurement position. As an example, an LDS can provide for combining multiple signatures to make leak detection systems more precise in terms of detecting leaks and avoiding false alarms. As an example, an LDS can include issuing one or more control instructions to equipment, which can be local and/or remote. For example, consider issuing a flow instruction to one or more pieces of a plant, issuing a control instruction to a vehicle (e.g., a drone, etc.), issuing a control instruction for acquiring sensor data, issuing a control instruction to one or more vessels (e.g., fishing, etc.) that may be navigating waters proximate to a plant or a portion thereof, etc.

As an example, an LDS can be a model-based pattern recognition and classification system that utilizes convex regions applied to leak detection in production systems.

As an example, an LDS can be implemented in an advisor framework (e.g., consider an OASE framework BASF SE, Ludwigshafen am Rhein, DE, etc.). In such an example, various sensor measurements may be provided, for example, via one or more interfaces.

As an example, an LDS can be a multivariable pattern-based leak detection system where signatures based on pressure measurements may be considered as to leaks to the surroundings.

As an example, an LDS can be described from basic building blocks, the signatures, to the main leak detector measure. As an example, in a production system with multiple subsea templates and transport pipelines, an LDS can be implemented in a hierarchical manner starting with the well instrumentation to form a well leak detector continuing with the pipelines to form pipeline leak detector and aggregating the different pipelines into sub-systems.

For example, consider an LDS divided into two sub-systems S12 and S34. Then again S12 consist of flowlines one and two (F1 and F2) and S34 consist of flowlines three and four (F3 and F4). In such an example, flowlines F1 and F2 interconnect three sub-sea manifolds (M1, M2 and M3) to the topside. In such an example, there were no transmitters on the sub-sea flowlines. That is, the sub-sea transmitters are located on the wellhead upstream the well isolation valves (PIV's). In such a system, there are topside pressure and temperature transmitter on the flowlines. Flowlines F3 and F4 interconnect a fourth subsea manifold (M4) to the topside.

In the example LDS, leak detector measures on the individual flowlines F1 to F4, leak detector measures for systems S12 and S34 were acquired and an overall leak detector measure. The system (plant) did not include well leak detectors.

As an example, an LDS can include (i) an interface to acquire on-line measurements in a relatively continuous manner where (ii) an on-line real time estimator model can provide for simulating the plant as if there were no leaks. In such an example, the LDS can include (iii) signatures to detect if there is particular difference between measured and estimated values can be utilized. As an example, an LDS may operate using (i) without (ii) and/or (iii). For example, consider a real time analysis LDS where regions are formed and utilized for comparisons with real time data for purposes of leak detection, which can include location and/or size estimation.

As an example, an LDS can include an ability to generate reconciled on-line measurements, a real time estimator calculating the behavior of the system as if there were no leaks, leak signatures, algorithms to combine the signatures into a leak detector measure and, for example, some extra functionality to make leak detectors robust against false alarms. As an example, a single signature can by itself be a leak detection measure; however, it may not be as robust as multivariable leak detectors with respect to measurement accuracy and false alarms.

As to signatures, a signature can be based on one or more of the following: (i) a single measurement, (ii) a combination of a single measurement and the corresponding simulated (e.g., OLGA estimated) value, or (iii) multiple measurements and the corresponding estimated values. As explained, an LDS may operate using a combination of a single measurement and a corresponding OLGA estimated value.

As an example, as to signature dependency on pipeline valves, an LDS can consider instances where on-line measurements behind a signature may become unavailable. For example, consider a transmission mode (wired and/or wireless), power, and/or sensor problem(s). As an example, a measurement may become inactive (not available) or fall out. Thus, signatures can have an activation signal. As an example, consider a well that can be routed to either of two transport flowlines F1 or F2 by proper setting of pipeline isolation valves (PIV's). If PIV1 (pipeline isolation valve towards F1) is open and PIV2 is closed (pipeline isolation valve towards F2), then the wellhead instrumentation can contribute towards signatures for flowline F1. If PIV1 is closed, then the wellhead instrumentation cannot contribute towards signatures for F1 since the wellhead is isolated from F1. The signature for F2 depends on PIV2 in a similar manner.

As to leak detection signatures with single measurement and an OLGA estimated value, consider a leak detection signature x_(i) that includes the following inputs:

-   -   e_(i)—estimated variable—shall be connected to an OLGA item         output     -   m_(i)—measured variable—shall be connected to a measured         variable from field     -   a_(i)—ambient/target value specific for (e_(i), m_(i))—it is a         constant parameter user input

Consider, for example, two different formulas for the signature:

$x_{i}\overset{\Delta}{=}\frac{e_{i} - m_{i}}{e_{i} - a_{i}}$ $x_{i}\overset{\Delta}{=}\frac{e_{i} - m_{i}}{{❘{e_{i} - a_{i}}❘} + {❘{m_{i} - a_{i}}❘}}$

As to scaling the signature, consider the following two inputs that can be used to described expected behavior of the signature x_(l):

-   -   μ_(x) _(i) —center (mean) value for signature x_(i)—it is a user         input parameter     -   r_(x) _(i) —radius (maximum) describing the variation for         signature x_(i)—it is a user input parameter

Then the scaled/normalized signature is given by:

${\overset{¯}{x}}_{i}\overset{\Delta}{=}\frac{x_{i} - \mu_{x_{i}}}{r_{x_{i}}}$

As to activation/deactivation of signatures, consider the following activation signals:

-   -   aact_(i)—automatic activation/deactivation of signature x_(i)         based on if measurement availability or other external settings.         Normally this is connected to the active signal of measurement         m_(i). In some cases, this activation signal will be connected         to a combination of other signals and valve settings. The         frontend script will specify the item for the activation signal.     -   mact_(i)—manual activation/deactivation of signature x_(i)—user         input.     -   gact—global activation/deactivation of all signatures         x_(i)—connected to the global signature activation/deactivation.         This is used during restart of LDS application to avoid false         alarms during startup

Activation/deactivation signal values may be, for example: value 1 (one) signal/indicate active, value 0 (zero) signal indicate inactive. A signature active signal then becomes:

act_(i)

aact_(i)·mact_(i)·gact

The active signature is:

{circumflex over (x)} _(i)

act_(x) _(i) ·x _(i)

As to binary output, zero/one output of {circumflex over (x)}_(i):

{tilde over (x)} _(i)

({circumflex over (x)} _(i)>1)+({circumflex over (x)} _(i)<−1)

As an example, a signature alarm item can be connected to GUI. For example, a signature alarm item based on {tilde over (x)}_(i) and act_(i) can be suited for the dynamical GUI element:

sa _(i)

(act_(i)<0.5)*3+(act_(i)≥0.5)·(({tilde over (x)} _(i)≥0.5)·0+({tilde over (x)} _(i)<0.5)·2)

-   -   sa_(i)=3—inactive     -   sa_(i)=2—active no alarm     -   sa_(i)=0—active alarm

Such output can be utilized by a computing device, a computing system, etc., to render an appropriate GUI to one or more displays.

As to signature inputs to populate, consider inputs to populate for each signature are:

-   -   a_(i)—ambient/target value     -   μ_(i)—mean or center value for the signature     -   r_(x) _(i) —Radius of region     -   mact_(i)—manual activation signal

As to signature outputs to populate, consider outputs to populate for each signature are:

-   -   x_(i)—Unscaled signature     -   x _(i)—Scaled signature     -   {circumflex over (x)}_(i)—Scaled signature multiplied with         activation act₁     -   {tilde over (x)}_(i)—Signature zero/one     -   act_(i)—Signature active     -   sa_(i)—Item for turning on/off alarm element in GUI

As to signature properties/attributes, consider, for example, properties/attributes of a signature:

-   -   Name—Signature name     -   Signature Type—To identify equation 1 or 2, will be expanded         later with more options, e.g., multivariable signatures etc.     -   Estimator Item—Name of estimated item e_(i) in Apis Hive     -   Measured Item—Name of measured item m_(i) in Apis Hive     -   Auto Activation Item—Name of auto activation item aact_(i) in         Apis Hive     -   Global Activation Item—Name of global activation item gact in         Apis Hive

As an example, an LDS can include multiple leak detectors. In the example below, a single leak detector ld_(j) is described.

A leak detector can make use of signatures x_(i) as inputs. For an LDS, it can include at least one signature. As explained, a signature may become inactive. When the number of active signatures is less than a minimum then the leak detector may become inactive.

As an example, an LDS can include various types of leak detectors (LDs). For example, consider three types where the difference between the types comes from how they combine multiple signatures into a leak detection measure. As an example, a single signature can be used in multiple leak detectors.

As an example, an LDS can provide a leak detector for each well, production pipeline, sub-network of pipelines (sub-systems) and an overall leak detector for a field consisting of wells and multiphase pipelines.

As an example, a hierarchical leak detection system can make it easier to traverse a tree structure to narrow down the position of the leak.

As an example, networks of production wells, manifolds and pipelines interconnected can be cast as a leak detection problem that is a multivariable problem. By making use of multiple signatures, considering vectors of signatures and the directionality of leaks, the system can become more robust (e.g., less sensitive to) with respect to measurement noise, measurement malfunction, model errors and assumptions etc.

As an example, a leak detector sum can be the sum of the available signatures:

${Id\_ sum}_{j} = {\sum\limits_{i = 1}^{n}x_{i}}$

As an example, a leak detector can be active if sum of signature activation signals ld_act_sum_(j)=Σ_(i=1) ^(n) act_(i) is greater than a minimum number of signatures multiplied with the manual activation signal for the leak detector:

ld_act_(j)

(ld _(act) _(sum) _(j)≥ ld_act_min_(j) )·ld_man_act_(j)

where

ld_act_min_(j) =min (ld_act_min_(j) ,ld_act_sum_(j))

As an example, a leak can be identified if a sum is greater than a leak detection limit, multiplied with the active signal:

ld _(j)

(ld _(sum) _(j) ≥ld_lim_(j))·ld_act_(j)

As an example, a leak detector alarm item can be connected to a dynamic GUI element, which may be interactive through one or more human input devices (HIDs), one or more signals, one or more instructions, etc.

As an example, a leak detector alarm item may be based on ld_(j) and ld_act_(j):

lda _(j)=(ld_act_(j)<0.5)*3+(ld_act_(j)≥0.5)·((ld _(j)≥0.5)·0+(ld _(j)<0.5)·2)

-   -   lda_(j)=3—inactive     -   lda_(j)=2—active no alarm     -   lda_(j)=0—active alarm

As an example, such output can be used by one or more dynamic GUI elements.

As an example, differences between three types of leak detectors can be based on what goes into the signature sum.

As an example, a leak detector can be based on minimum volume ellipsoids where, for example, axis aligned ellipsoids fit in the leak detector description of an LDS.

As to a point leak detector, consider a point leak detector sum defined as:

${Id\_ sum}_{j} = {\sum\limits_{i = 1}^{n}{\overset{˜}{x}}_{i}}$

Note, the signatures x; are zero if they are inactive so inactive signatures do not contribute, thus an LDS can sum over the configured signatures.

Also, {tilde over (x)}_(i) can be a zero/one value defined to be one if {tilde over (x)}_(i)>1 or {tilde over (x)}_(i)<−1 and zero if −1≤{tilde over (x)}_(i)≤1. In other words, a point leak detector sum is the sum of the signatures identifying a leak.

As an example, a leak can be signaled by an LDS if the point leak detector sum ld_sum_(j) is greater than a limit ld_lim_(j).

As to a linear leak detector, consider a linear leak detector sum defined as:

${Id\_ sum}_{j} = {\sum\limits_{i = 1}^{n}{❘{\overset{\hat{}}{x}}_{i}❘}}$

Above, the sum is of the scaled signatures, so the non-zero signatures contribute. Note, the signatures {circumflex over (x)}_(i) can be zero if they are inactive so inactive signatures do not contribute.

As an example, consider axes aligned ellipse for leak detection. In such an example, an axes aligned ellipse leak detector sum can be defined as:

${Id\_ sum}_{j} = {\sum\limits_{i = 1}^{n}{\overset{\hat{}}{x}}_{i}^{2}}$

Above, the sum is of the scaled signatures, so the non-zero signatures contribute. Note, the signatures {circumflex over (x)}_(i) can be zero if they are inactive so inactive signatures do not contribute.

As an example, leak detector inputs to populate can include:

-   -   ld_act_min_(j)—Minimum number of signatures required to be         active for leak detector to become active     -   ld_man_act_(j)—Manual activation signal for leak detector, 1         means active, 0 means inactive     -   ld_lim_(j)—Limit for detecting a leak

As an example, leak detector outputs to populate can include:

-   -   ld_sum_(j)—sum of leak detector signatures     -   ld_act_sum_(j)—number of active signatures     -   ld_act_(j)—leak detector is active (value 1) or inactive (value         zero)     -   ld_(j)—leak detector measure, value one indicates a leak, value         zero indicates no leak     -   lda_(j)—leak detector alarm to be used by GUI

As an example, leak detector properties/attributes can include:

-   -   Name—Leak detector name     -   Type—To identify point, linear or ellipse-based combination of         signatures     -   Signatures—List of signatures identified by name

As to combining leak detectors, consider one or more of the following: (a) demand that one or more leak detector measures ld_(j) to become one; and (b) sum multiple leak detector sums ld_sum_(j) in the same way as a leak detector sum signatures and apply the same logic as for a leak detector.

As an example, an LDS may implement one or more time filtering techniques and/or other time processing techniques. For example, consider a time filtering (delay) approach on leak detection measure. As an example, an LDS may synchronize data acquisition, may interpolate data between measured times (e.g., sensor timestamps, etc.), etc.

As an example, an LDS can include time filtering that aims to reduce number and/or risk of false positives (e.g., false alarms), which may occur due to high frequency (e.g., with enough amplitude) changes in one or more measured variables. As an example, a filter can demand that a leak detector signal is true (e.g., binary value one) for at least 1 to 3 minutes for the measure to become active. As an example, an LDS may have a start-up period during which various checks are made to assure that measurements are being acquired and that the measurements make sense. In such an example, the LDS may generate noise assessments as to one or more channels. As an example, an LDS may operate using one or more noise assessments that may be for one or more measurements, measurement channels, etc. As an example, one or more approaches to leak detection may consider noise.

FIG. 29 shows an example of a GUI 2900 that includes a graphic of a system with multiple flowlines where various positions are indicated that can demarcate segments that can be analyzed with respect to leaks, for example, for leak detection. As shown, the GUI 2900 can include a graphic that indicates status (e.g., using color, etc.).

As an example, a GUI may render at least a portion of a network, which may be, for example, subsea loop. Consider as an example a loop with 8 wells, pairwise wells (CP4, CP8) can be routed to either FL3 or FL4 using. In such an example, pipeline isolation valves may be utilized. As an example, wells CP4 and CP8 may be routed to FL4.

As to wellhead instrumentation, each well can include three pressure and three temperature transmitters and a multiphase flow meter (MPFM) for measuring gas, oil, and water rate, which can contribute to signature on inlet of FL4. In such an example, four leak detection signatures may be generated, two subsea at inlet of FL3 and FL4 and two topside at outlet of FL3 and FL4. As an example, one or more complex loops may be tracked with three manifolds, 17 wells, 8 subsea LD signatures and two topside for a total of 10 LD signatures.

FIG. 30 shows an example of a GUI 3000 that includes various equipment that can be topside, for example, a topside of FL3 and a topside of FL4. As with the GUI 2900, various graphics can be utilized to indicate status (e.g., green means no detected leaks, no transients trending to leak regions, etc.). As an example, a green indicator may mean no leaks, a yellow indicator may mean transient trending in a direction out of a normal operational region, and a red indicator may mean a leak has been detected. As an example, a moving graphic may be utilized to indicate an estimated location of a leak. For example, consider a graphic that moves as more data are acquired where such data can increase confidence in where a leak may be located. As an example, the size of an indicator may provide an indication of size of a leak. For example, a large diameter can be used for a larger leak and a smaller diameter for a smaller leak.

FIG. 31 shows an example of a GUI 3100 that includes various equipment and an indicator graphic for hydrate monitoring for FL1. In such an example, data for hydrate monitoring and/or flow rate (e.g., gas and/or liquid) may be utilized by an LDS.

As explained, one or more signatures may be visualized in one or more multidimensional spaces, which may include one or more regions that can demarcate behaviors as to operation (e.g., leak/no leak, sensor OK, sensor NOK, etc.).

FIG. 32 shows an example of a GUI 3200 that includes a three-dimensional (3D) plot that includes a vertical axis with a central value c where two horizontal planes are located at r+c and −r+c, respectively. As explained, a leak signature can be defined for a distance to ambient/target. For example, consider a leak signature X_(i) for position i depending on measurement or inferred measurement M_(i), on-line model estimates E_(i) corresponding to measurement M_(i) and ambient/target value A_(i) is given by:

$X_{i} = \frac{E_{i} - M_{i}}{E_{i} - A_{i}}$

In FIG. 32 , the plot of the GUI 3200 includes a surface with A_(i)=12 and E_(i) and M_(i) in the range of 1 to 23 (11 below A_(i) and 11 above A_(i)).

FIG. 33 shows an example of a GUI 3300 that includes a 3D plot where a signature can be given by:

${\overset{\sim}{X}}_{i} = \frac{E_{i} - M_{i}}{{❘{E_{i} - A_{i}}❘} + {❘{M_{i} - A_{i}}❘}}$

In FIG. 33 , the plot of the GUI 3300 includes a surface with A_(i)=12 and E_(i) and M_(i) in the range of 1 to 23 (11 below A_(i) and 11 above A_(i)).

FIG. 34 shows an example of a GUI 3400 that includes a 3D plot where a signature can be given by:

${\hat{X}}_{i} = \frac{E_{i} - M_{i}}{\sqrt{\left( {E_{i} - A_{i}} \right)^{2} + \left( {M_{i} - A_{i}} \right)^{2}}}$

In FIG. 34 , the plot of the GUI 3400 includes a surface with A_(i)=12 and E_(i) and M_(i) in the range of 1 to 23 (11 below A_(i) and 11 above A_(i)).

As an example, no leak operation can be represented by a surface between planes such that as long as operation is between the two planes then there is no leak for a corresponding signature. As an example, an operator may be able to adjust one or more boundaries and/or provide for automatic adjustment of one or more boundaries (e.g., responsive to one or more conditions, etc.). For example, where a sensor may be experiencing an issue, a boundary may be adjusted to account for the sensor related issue. As an example, one or more of the GUIs 3200, 3300 and 3400 may be customizable as to color, axes, number of planes or other boundaries, etc. As shown, projections may be made from a 3D surface onto a plane, which may be a base plane. As data are acquired in real time, one or more signatures may change, which may be projected and/or otherwise visualized. As an example, an LDS may provide for user interaction with a GUI or GUIs to insert one or more boundaries, move one or more boundaries, etc. (e.g., alarm boundaries, etc.).

As explained, an LDS may be implemented in one or more types of environments for one or more types of systems. As explained, FIG. 8 shows an example of a system architecture 800, which may be implemented using one or more types of computing platforms, frameworks, etc. As an example, an LDS may be implemented locally and/or remotely.

As an example, a method can include receiving real time data where the real time data include at least pressure sensor data from multiple pressure sensors of a hydrocarbon fluid production network for multiple locations in the hydrocarbon fluid production network; generating an expected operational region in a multidimensional domain using at least a portion of the real time data; operating a leak detection system using the expected operational region; tracking at least a portion of the real time data in the multidimensional domain; and issuing a leak detection signal responsive to the tracking indicating an excursion from the expected operational region, where the leak detection signal indicates the presence of a leak in the hydrocarbon fluid production network. In such an example, the tracking at least a portion of the real time data in the multidimensional domain can include tracking real time data for at least two of the multiple locations. For example, consider multiple locations that can include wellhead locations. As an example, wellhead locations can include corresponding wells that are in fluid communication with a common reservoir. In such an example, behavior at one wellhead may result in corresponding behavior at one or more other wellheads.

As an example, a hydrocarbon fluid production network can include at least one portion without a leak sensor. For example, consider an LDS that operates using sensor data from equipment sensors that are not expressly for leak sensing. In such an example, the equipment sensors may be part of wellhead equipment where such equipment sensors generate pressure and/or other data at or proximate to a wellhead. Such equipment sensors may be part of a wellhead assembly (e.g., a Christmas tree, etc.).

As an example, an expected operational region can be a convex hull. For example, consider an ellipsoid as a convex hull or, for example, a convex hull of ellipsoids.

As an example, tracking can generate a transient region in a multidimensional space where, for example, the transient region can be a convex hull. As an example, a transient region may be provided via simulation and may be revised using real time data.

As an example, a method can include refining at least one of an estimated leak location in real time and an estimated leak size in real time. As an example, a method can include transmitting instructions to dynamically render at least one graphic to a display that indicates at least one of an estimated leak location in real time and an estimated leak size in real time.

As an example, an expected operational region can characterize fluid communication between at least two of the multiple locations. For example, consider an expected operational region that characterizes fluid communication between at least two of multiple locations of a hydrocarbon fluid production network via a reservoir.

As an example, a leak can be an outward leak or an inward leak.

As an example, a leak can exhibit directionality in a multidimensional space. For example, consider directionality that corresponds to location where the directionality may point to one of two locations where a leak is between the two locations. As an example, tracking can include assessing one or more-time related aspects. For example, a large leak may move more rapidly in a multidimensional space than a smaller leak. As an example, it may take a longer time (real time) for a small leak transient to have an excursion outside of an expected operational region. As mentioned, a leak can also exhibit directionality. As an example, tracking can include assessing leak size and leak location dynamically using real time data.

As an example, an LDS can acquire pressure sensor data from multiple pressure sensors of a hydrocarbon fluid production network for multiple locations in the hydrocarbon fluid production network to impart redundancy that increases confidence of the LDS.

As an example, a method may alter, adjust, revise, etc., an operational region responsive to one or more operational changes. For example, consider using an operational schedule where a scheduled event can result in a change in operational region (e.g., an expected operational region, etc.).

As an example, a method can include utilizing a real time model to generate simulated data during operation of a hydrocarbon fluid production network and comparing at least a portion of the real time data to at least a portion of the simulated data.

As an example, a method can include receiving real time data that can include at least one of multiphase flow sensor data, temperature sensor data, salinity sensor data, viscosity sensor data, water break sensor data, emulsion sensor data, and density sensor data.

As an example, a method can include using an expected operational region that is a no leak region. In such a method, tracking within the expected operational region can be characterized as normal behavior unless the tracking fits within a leak transient region that includes a region that is outside of the expected operational region. As an example, a method can include testing a real time data against one or more transient regions as associated with evolution of leaks. For example, a testing approach can help to identify a type of leak while in a transient stage.

As an example, a method can include performing leak detection in a hydrocarbon fluid production network with a manifold where multiple pipelines join the manifold.

As an example, an LDS can operate using characterization. As an example, an LDS can operate using characterization and classification. As an example, an LDS can operate using classification. As an example, an LDS can operate using real time characterization and/or real time classification. As an example, an LDS can operate using model-based pattern recognition and classification based on convex regions applied to leak detection in one or more production systems.

As an example, a leak detection system can include a processor; memory accessible by the processor; and processor-executable instructions stored in the memory where the instructions include instructions to instruct the leak detection system to: receive real time data where the real time data include at least pressure sensor data from multiple pressure sensors of a hydrocarbon fluid production network for multiple locations in the hydrocarbon fluid production network; generate an expected operational region in a multidimensional domain using at least a portion of the real time data; operate a leak detection system using the expected operational region; track at least a portion of the real time data in the multidimensional domain; and issue a leak detection signal responsive to the tracking indicating an excursion from the expected operational region, where the leak detection signal indicates the presence of a leak in the hydrocarbon fluid production network.

As an example, one or more computer-readable storage media can include computer-executable instructions executable by a computer, the instructions include instructions to: receive real time data where the real time data include at least pressure sensor data from multiple pressure sensors of a hydrocarbon fluid production network for multiple locations in the hydrocarbon fluid production network; generate an expected operational region in a multidimensional domain using at least a portion of the real time data; operate a leak detection system using the expected operational region; track at least a portion of the real time data in the multidimensional domain; and issue a leak detection signal responsive to the tracking indicating an excursion from the expected operational region, where the leak detection signal indicates the presence of a leak in the hydrocarbon fluid production network.

In some embodiments, the methods of the present disclosure may be executed by a computing system. FIG. 35 illustrates an example of such a computing system 3500, in accordance with some embodiments. The computing system 3500 may include a computer or computer system 3501-1, which may be an individual computer system 3501-1 or an arrangement of distributed computer systems such as systems 3501-2, 3501-3 and 3501-4. The computer system 3501-1 includes instructions 3502 that are configured to perform various tasks according to some embodiments, such as one or more methods disclosed herein. To perform these various tasks, the instructions 3502 can execute independently, or in coordination with, one or more processors 3504, which is (or are) connected to one or more storage media 3506. The processor(s) 3504 is (or are) also connected to a network interface 3507 to allow the computer system 3501-1 to communicate over a data network 3509 with one or more additional computer systems and/or computing systems, such as 3501-2, 3501-3, and/or 3501-4 (note that computer systems 3501-2, 3501-3 and/or 3501-4 may or may not share the same architecture as computer system 3501-1, and may be located in different physical locations, e.g., computer systems 3501-1 and 3501-2 may be located in a processing facility, while in communication with one or more computer systems such as 3501-3 and/or 3501-4 that are located in one or more data centers, and/or located in varying countries on different continents).

A processor may include a microprocessor, microcontroller, processor module or subsystem, programmable integrated circuit, programmable gate array, or another control or computing device.

The storage media 3506 may be implemented as one or more computer-readable or machine-readable storage media. Note that while in the example embodiment of FIG. 35 storage media 3506 is depicted as within computer system 3501-1, in some embodiments, storage media 3506 may be distributed within and/or across multiple internal and/or external enclosures of computing system 3501-1 and/or additional computing systems. Storage media 3506 may include one or more different forms of memory including semiconductor memory devices such as dynamic or static random access memories (DRAMs or SRAMs), erasable and programmable read-only memories (EPROMs), electrically erasable and programmable read-only memories (EEPROMs) and flash memories, magnetic disks such as fixed, floppy and removable disks, other magnetic media including tape, optical media such as compact disks (CDs) or digital video disks (DVDs), BLUERAY® disks, or other types of optical storage, or other types of storage devices. Note that the instructions discussed above may be provided on one computer-readable or machine-readable storage medium, or alternatively, may be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly plural nodes. Such computer-readable or machine-readable storage medium or media is (are) considered to be part of an article (or article of manufacture). An article or article of manufacture may refer to any manufactured single component or multiple components. The storage medium or media may be located either in the machine running the machine-readable instructions or located at a remote site from which machine-readable instructions may be downloaded over a network for execution.

It may be appreciated that computing system 3500 is an example of a computing system, and that computing system 3500 may have more or fewer components than shown, may combine additional components not depicted in the example embodiment of FIG. 35 , and/or computing system 3500 may have a different configuration or arrangement of the components depicted in FIG. 35 . The various components shown in FIG. 35 may be implemented in hardware, software, or a combination of both hardware and software, including one or more signal processing and/or application specific integrated circuits.

Further, the steps in the processing methods described herein may be implemented by running one or more functional components in information processing apparatus such as general-purpose processors or application specific chips, such as ASICs, FPGAs, PLDs, or other appropriate devices. Such components, combinations of these components, and/or their combination with general hardware may be utilized as part of a system and/or to implement one or more methods.

Geologic interpretations, models, and/or other interpretation aids may be refined in an iterative fashion; this concept is applicable to the methods discussed herein. This may include use of feedback loops executed on an algorithmic basis, such as at a computing device (e.g., computing system 3500, FIG. 35 ), and/or through manual control by a user who may make determinations regarding whether a given step, action, template, model, or set of curves has become sufficiently accurate for the evaluation of the subsurface three-dimensional geologic formation under consideration.

As an example, a system may be a distributed environment, for example, a so-called “cloud” environment where various devices, components, etc. interact for purposes of data storage, communications, computing, etc. As an example, a device or a system may include one or more components for communication of information via one or more of the Internet (e.g., where communication occurs via one or more Internet protocols), a cellular network, a satellite network, etc. As an example, a method may be implemented in a distributed environment (e.g., wholly or in part as a cloud-based service).

FIG. 36 shows components of an example of a computing system 3600 and an example of a networked system 3610 that includes a network 3620. The system 3600 includes one or more processors 3602, memory and/or storage components 3604, one or more input and/or output devices 3606 and a bus 3608. In an example embodiment, instructions may be stored in one or more computer-readable media (e.g., memory/storage components 3604). Such instructions may be read by one or more processors (e.g., the processor(s) 3602) via a communication bus (e.g., the bus 3608), which may be wired or wireless. The one or more processors may execute such instructions to implement (wholly or in part) one or more attributes (e.g., as part of a method). A user may view output from and interact with a process via an I/O device (e.g., the device 3606). In an example embodiment, a computer-readable medium may be a storage component such as a physical memory storage device, for example, a chip, a chip on a package, a memory card, etc. (e.g., a computer-readable storage medium).

In an example embodiment, components may be distributed, such as in the network system 3610. The network system 3610 includes components 3622-1, 3622-2, 3622-3, . . . 3622-N. For example, the components 3622-1 may include the processor(s) 3602 while the component(s) 3622-3 may include memory accessible by the processor(s) 3602. Further, the component(s) 3622 may include an I/O device for display and optionally interaction with a method. The network may be or include the Internet, an intranet, a cellular network, a satellite network, etc.

Although only a few example embodiments have been described in detail above, those skilled in the art will readily appreciate that many modifications are possible in the example embodiments. Accordingly, all such modifications are intended to be included within the scope of this disclosure as defined in the following claims. In the claims, means-plus-function clauses are intended to cover the structures described herein as performing the recited function and not only structural equivalents, but also equivalent structures. Thus, although a nail and a screw may not be structural equivalents in that a nail employs a cylindrical surface to secure wooden parts together, whereas a screw employs a helical surface, in the environment of fastening wooden parts, a nail and a screw may be equivalent structures. 

What is claimed is:
 1. A method comprising: receiving real time data wherein the real time data comprise at least pressure sensor data from multiple pressure sensors of a hydrocarbon fluid production network for multiple locations in the hydrocarbon fluid production network; generating an expected operational region in a multidimensional domain using at least a portion of the real time data; operating a leak detection system using the expected operational region; tracking at least a portion of the real time data in the multidimensional domain; and issuing a leak detection signal responsive to the tracking indicating an excursion from the expected operational region, wherein the leak detection signal indicates the presence of a leak in the hydrocarbon fluid production network.
 2. The method of claim 1, wherein tracking at least a portion of the real time data in the multidimensional domain comprises tracking real time data for at least two of the multiple locations.
 3. The method of claim 1, wherein the multiple locations comprise wellhead locations.
 4. The method of claim 3, wherein the wellhead locations comprise corresponding wells that are in fluid communication with a common reservoir.
 5. The method of claim 1, wherein the expected operational region comprises a convex hull.
 6. The method of claim 5, wherein the convex hull is an ellipsoid.
 7. The method of claim 1, wherein the tracking generates a transient region in the multidimensional space.
 8. The method of claim 7, wherein the transient region comprises a convex hull.
 9. The method of claim 1, comprising refining at least one of an estimated leak location in real time and an estimated leak size in real time.
 10. The method of claim 9, comprising transmitting instructions to dynamically render at least one graphic to a display that indicates at least one of the estimated leak locations in real time and the estimated leak size in real time.
 11. The method of claim 1, wherein the expected operational region characterizes fluid communication between at least two of the multiple locations.
 12. The method of claim 1, wherein the expected operational region characterizes fluid communication between at least two of the multiple locations via a reservoir.
 13. The method of claim 1, wherein the leak comprises an outward leak or an inward leak.
 14. The method of claim 1, wherein the pressure sensor data from multiple pressure sensors of the hydrocarbon fluid production network for multiple locations in the hydrocarbon fluid production network impart redundancy that increases confidence of the leak detection system.
 15. The method of claim 1, comprising utilizing a real time model to generate simulated data during operation of the hydrocarbon fluid production network and comparing at least a portion of the real time data to at least a portion of the simulated data.
 16. The method of claim 1, wherein the real time data comprise at least one of multiphase flow sensor data, temperature sensor data, salinity sensor data, viscosity sensor data, water break sensor data, emulsion sensor data, and density sensor data.
 17. The method of claim 1, wherein the expected operational region is a no leak region.
 18. The method of claim 1, wherein the hydrocarbon fluid production network comprises a manifold wherein multiple pipelines join the manifold.
 19. A leak detection system comprising: a processor; memory accessible by the processor; and processor-executable instructions stored in the memory wherein the instructions comprise instructions to instruct the leak detection system to: receive real time data wherein the real time data comprise at least pressure sensor data from multiple pressure sensors of a hydrocarbon fluid production network for multiple locations in the hydrocarbon fluid production network; generate an expected operational region in a multidimensional domain using at least a portion of the real time data; operate a leak detection system using the expected operational region; track at least a portion of the real time data in the multidimensional domain; and issue a leak detection signal responsive to the tracking indicating an excursion from the expected operational region, wherein the leak detection signal indicates the presence of a leak in the hydrocarbon fluid production network.
 20. One or more computer-readable storage media comprising computer-executable instructions executable by a computer, the instructions comprising instructions to: receive real time data wherein the real time data comprise at least pressure sensor data from multiple pressure sensors of a hydrocarbon fluid production network for multiple locations in the hydrocarbon fluid production network; generate an expected operational region in a multidimensional domain using at least a portion of the real time data; operate a leak detection system using the expected operational region; track at least a portion of the real time data in the multidimensional domain; and issue a leak detection signal responsive to the tracking indicating an excursion from the expected operational region, wherein the leak detection signal indicates the presence of a leak in the hydrocarbon fluid production network. 